Oracle java is based on openjdk with patented bits added:
- Sometimes these bits should increase performance (jrockit traces ...),
- Sometimes these bits improve compatibility (because they were inherited from SUN and authors of applications tested against them since SUN). Most of the "stability" attributed to Oracle / Sun java is simply by application authors who learn to avoid Oracle / Sun patented bit errors and add workarounds that work on jvms without these errors (see Also: IE6)
Red Hat java is based only on openjdk
- clean openjdk integrates better with the system. Openjdk guys try to remove residual java-isms and use the same conventions as other system applications
- pure openjdk is more facing forward. Oracle knows that SUN nearly killed Java with Byzantine combinations of proprietary technologies that it could not afford to support. All that Oracle needs in the long run will end in openjdk. It is enough for openjdk to achieve parity with proprietary bits for Oracle to kill them - there is no $$$ in supporting proprietary technology when similar free technologies are available.
- For Red Hat, it is very often necessary to reserve the code written for the next version of openjdk in the current redhat java when it solves the problem in this version (while the current API remains), while Oracle will strive to wait for the next version of openjdk before offering her.
As far as I know, Oracle was completely distracted by the way the SUN handled java 1.6 (it was called java 1.6, but the development was not linear, and all the desktop / server / windows / linux jvms scripts were different from the bits added to one version that could not be used in another because of the coding of labels and complex licensing agreements, each of which somehow lagged behind the others). Oracle intends to support the classic linear development channel: openjdk next -> current openjdk -> oracle java
Depending on which version you are using, you need to apply the security updates published by its maintainer. It is useless to use Oracle Java as an update for Red Hat java, or vice versa, this is slightly different code with slightly different security errors. Both companies have capable engineers and share openjdk trunk security fixes. When fixed assemblies are published, they depend on embargo agreements and security policies. Oracle will seek batch fixes in rare pre-planned releases if there is no critical vulnerability. Red Hat will publish as soon as it has something to do with security, whether large or small. Red Hat build processes are more flexible than those used by Oracle. Linux build processes are 100% automated, and Oracle needs to worry about Windows and Co.
Finally, Oracle Java published in RHEL is a repackaging of Oracle files to use Linux-based packaging technology and uses the same paths (etc.) as openjdk packages (which makes it easy to replace them with another), while Oracle Java as published Oracle still follows very strange Solaris / windows SUN naming and routing conventions that people think are suitable for Linux. It should have no more and no less security vulnerabilities than Oracle Java published by Oracle (for the same version), it is simply much more convenient to deploy it. It is intended for just another set of Linux packages that can be deployed on many Linux servers using its own package deployment systems. When you have hundreds of servers to manage, this is a great help to not have a special jvm case.
Every year in February, Red Hat and Oracle top java people meet in public at fosdem and present their current priorities. If you are interested, you can consult their past presentations in the fosdem public archives.