回答:
これはOpenJDKページで詳細に説明されています：JDK 7 Update Project Proposal Q＆A
このプロジェクトは、Oracle JDK 7 Updateリリースのベースとして機能しますか？
はい。
OpenJDK 6に関する Joe DarcyのFOSDEM ブログ投稿から引用するには：
特に、OpenJDK 6と6のアップデートトレインの間にあるように、OpenJDK 7のコードベースと7のアップデートコードベースの間には同じ二分法はありません...
私の見解によれば、上記は本質的に、パッチと更新が通常最初にOpen JDKに送信され、次に可能な限り小さな遅延でOracle JDKに配信されることを意味します。
セキュリティパッチの場合、状況は逆のように見えます。つまり、最初にOracleリリースに移動し、次に（可能な限り少し遅れて）OpenJDKに移動することを期待します。
7 Update ProjectはOracleからセキュリティ修正を受け取りますか？
はい。
OpenJDK 6と同様に、セキュリティ修正は最初に秘密にされ、プライベートフォレストに適用されてから、影響を受けるJDKリリーストレインに対する修正の一般的な同期公開の一部としてパブリックフォレストにプッシュされます。さらに、彼らは公開のコードレビューとプットバックの承認プロセスを通過せず、プロジェクトの課題追跡に対応する問題は公開されません。
このプロジェクトはいつOracleからセキュリティ修正を受け取りますか？
Oracle Java SE Critical Patch Updatesのスケジュールは公開されています。
このプロジェクトのソースコードのセキュリティ修正は、Oracleの製品でリリースされるのとほぼ同時にJDK 7 Updateプロジェクトで利用可能になります...
OracleとOpen JDKの同期を維持するために多大な労力が費やされている理由をよりよく理解するには、前のプロジェクトに関するOracleの決定を見てみることは理にかなっています。公式のJava SE 7リファレンス実装としてのOpenJDKへの移行：
... OracleとJava SE 7エキスパートグループの他のメンバーは、Java SE 7仕様（JSR 336）に最後の仕上げを行っています。仕様リードとしての役割において、OracleはJava SE 7リファレンス実装を提供する責任があります。OpenJDKオープンソースコードに完全に基づいたリファレンス実装を提供し、GPLオープンソースライセンスの下で利用できるようにします。 。
リファレンス実装（RI）の役割は、すべてのJava実装のゴールドスタンダードとして使用されます。Java SE互換として認定された実装を実現するには、実装者は多数の互換性テストであるTechnology Compatibility Kit（TCK）に合格する必要があります。さらに、互換性の追加チェックとして実装をRIと比較できます。基本的に、実装がRIと同じ動作をすることが認定されている場合、Java互換です。このトピックの詳細については、JCP FAQを参照してください。
これまで、Sunは常にSun JDKをRIとして使用し、バイナリコードライセンス（BCL）の下で使用できるようにしてきました。これは、その製品実装が定義上互換性があることを意味するため、Sunにとって非常に便利でした。ただし、Sun JDKには、Javaプラグインなど、標準に含まれていない機能がかなり多く含まれていたため、混乱も招きました。また、オープンソースの実装者は公式のRIソースコードを調査および評価できないため、この慣行を続けると事態が困難になります。（Oracle JDKのソースコードはOpenJDKとは少し異なります。これから先に取り組む予定です）。
これを念頭に置いて、Oracleは次のことを行います。
- OpenJDKコードベースのみに基づいてRIバイナリを作成します。
- 商用の実装者にはBCL（通常のJavaライセンス）で、オープンソースの実装者にはGPLv2（クラスパスを除く）の下でRIバイナリを利用できるようにします。
- TCKを商用ライセンシーに提供し続けますが、Java SE 7をカバーするようにOCTLAライセンスも更新します。後者により、オープンソースの実装者がTCKに無料でアクセスして、実装を確認できます...
上記の決定は、正式に検証、テスト、ライセンスされ、準拠したコードをリリースするために、Open JDKコードに投入する多くの努力を意味します。合意された公開スケジュールに従ってリリースする必要があることを追加すると、そのような努力は以前の「従来の」Sun / Oracle Javaリリースで行われたのとほぼ同じになることが明らかになります。
これにより、OpenとOracle JDKのコードベースをできるだけ近づけることが妥当になります。そうしないと、開発と修正の重複により、両方のプロジェクトがTCKに準拠するようになり、法外に困難になる可能性があります。
参照実装としてOpen JDKを使用する決定は、Oracleの最大の関心事として、JDKをOpen JDKのリリースまで、JDKをOpen JDKと可能な限り近づけることにしたようです。
Oracleが言及した同期をさらに維持する動機となるものを理解するには、JDK 7の更新リリースで、Open JDK 8のプロジェクトに注目する必要があります。
このプロジェクトの目的は、Java Community ProcessでJSR 337によって定義される、Java SE 8プラットフォームのオープンソースのリファレンス実装を作成することです。
JDK 7のリファレンス実装に関して上記で説明したのと同じ理由で、両方のJDKの更新をできるだけ同期させることは、やはりOracleの最大の利益になります。
現在、これらのJDK間の違いが大きいほど、独自のリリースをTCKに準拠させるために必要な作業が重複するため、OracleがJava SE 8をリリースするのが難しくなります。反対も当てはまります。つまり、両方のプロジェクトが近くなればなるほど、両方のJava 8実装をリリースするために必要な労力が少なくなります。
異なるクライアントを対象として、同じソフトウェアの2つのわずかに異なるバージョンを同時にサポートすることはありませんか？もしそうなら、あなたはそれらをできるだけ近くに保ちたいという欲求と、これらが同期していなかったときに経験した不便を覚えているでしょう。Open JDKとOracle JDKを使用すると、大規模な場合に限り、これは非常に似ています。
ほとんどすべてのバグ修正は、OpenJDKプロジェクトを直接経由して、ダウンストリームのJVMベンダー（Oracle、Azul、RedHatなど）に入ります。
例外として、OpenJDKに静かに移植される前に、一部のセキュリティパッチがダウンストリームバージョン（特にOracle）で修正されています。これにより、ベンダーはオープンソースプロジェクトの脆弱性を公表する前に、セキュリティ修正で世界のほとんどをアップグレードできます。
一部のベンダーは、変更をOpenJDKにプッシュしないことも選択しています。たとえば、GoogleとTwitterの両方でOpenJDKのバージョンが変更されており、メインのOpenJDKプロジェクトに戻されていないバグ修正と機能が内部で使用されています。
HTH