Oracle java is based on openjdk with some proprietary bits added:

– Sometimes those bits are supposed to increase performance (jrockit traces…),

– Sometimes those bits will improve compatibility (because they've been inherited from SUN and app authors tested against them since SUN era). A lot of the "stability" attributed to Oracle/Sun java is just app authors learning to avoid the bugs of Oracle/Sun proprietary bits, and adding workarounds that trip on jvms without those bugs (see also : IE6)

Red Hat java is based on the openjdk only

– pure openjdk is better integrated with the system. The openjdk guys try hard to remove residual java-isms and use the same conventions as other system apps

— pure openjdk is more forward facing. Oracle knows that SUN almost killed Java with byzantine combinations of proprietary tech it couldn't afford to maintain. Anything Oracle needs long term will end up in openjdk. It is sufficient for the openjdk implementation to achieve parity with the proprietary bits for Oracle to kill them – no $$$ in maintaining proprietary tech when similar free tech is available.

– it is very common for Red Hat to backport the code written for the next openjdk version in current redhat java, when it solves a problem in this version (as long as the current API is conserved), while Oracle will tend to wait for this next openjdk version before proposing it.

To my knowledge Oracle has been thoroughly disgusted by the way SUN handled java 1.6 (it was called java 1.6 but development was not linear, desktop/server/windows/linux jvms were all different with bits added in one version that could not be used in another due to coding shortcuts and complex licensing agreements, each of them lagged the others one way or another). Oracle intends to maintain a classic linear development pipe: openjdk next → current openjdk → oracle java

Whichever version you use you need to apply the security updates published by its maintainer. It's useless to use Oracle java as update to Red Hat java or vice versa, it's slightly different code with slightly different security bugs. Both companies have capable engineers and share security fixes in the openjdk trunk. When the fixed builds are published depend on embargo agreements and security fix policies. Oracle will tend to batch fixes in infrequent pre-planned releases, unless there is a critical vulnerability. Red Hat will publish as soon as there is something security-related to fix, be it big or small. Red Hat build processes are more agile than those Oracle uses. The Linux build processes are 100% automated, while Oracle needs to worry about windows & co.

Lastly Oracle Java as published in RHEL is a repackaging of Oracle files to use native Linux packaging tech and use the same path (etc) conventions as the openjdk packages (making it easy to replace one with another), while Oracle Java as published by Oracle still follows the very strange naming and path conventions SUN Solaris/windows people thought appropriate on Linux. It should have no more and no less security vulnerabilities than Oracle Java as published by Oracle (for the same version), just be a lot more convenient to deploy. It is designed to be just another linux package set, that can be deployed on many linux servers using native package deployment systems. When you have hundreds of servers to manage it is a great help not to have to special-case the jvm.

Each year in february Red Hat and Oracle top java people meet publicly at fosdem and present their current priorities.If you're interested you can consult their past presentations in fosdem public archives.