JDK7を再考する 、というタイトルの投稿で（そして jdk7-devにも、クロスポストされている）、 Mark Reinhold氏は、リリースを遅くするのではなく、早めるために、以前JDK7に計画されていた内のあるものは、JDK8まで延ばす、という提案した。この提案が、これはいい考えなのか悪い考えなのかについて、様々な議論を巻き起こした。
以前発表された予定表（とにかく、最初から守れそうなものではなかった）がずれる原因となったJDKの遅れを受け入れているので、現在の議論は、現在サポートできているもので、その前にリリースすべきか、すべてが揃うまで待つべきかに、集中している。氏が提案するのは：
この「 Plan B」の見積りですが、2011年半ばに、削られたJDK7を、2012年の後半にJDK8をリリースできる見込みです。
要約すると:
- Plan A: JDK 7 （ 現在の予定通り）2012年半ば
- Plan B: JDK 7 （ ラムダ式, Jigsawを除き、Coin の一部）2011年半ば
- Plan B: JDK 8 （ ラムダ式, Jigsaw、Coinの残り、更にプラス）2012年の後半
皮肉にも、氏のブログのタイトルは、「一刻の猶予もない！」であるが、投稿に寄せられたいくつものコメントが言うように、リリースが全く無いより、早く、頻繁にリリースがあったほうがよい。Plan Bのフィーチャセットには、非常に望まれるものがいくつかある（そして、あまり期待していないものも）が、 Project CoinのPlan Bの部分は、Java言語にとって有益であることは、疑う余地がない。Joseph D. Darcy 氏によって明らかにされた 、これらには以下のものを含む：
- Binary リテラルとリテラルにおけるUnderScore
- switchにおけるstring
- diamond オペレータ
- 改善された例外処理
- 単純化されたvarargs メソッドの呼び出し
- resources ブロック付きの
try
Plan Bは、また jsr166y クラス (ForkJoin, TransferQueue, Phaser)を含む。更に別のJVMの改善が、JVMレベルであり、JSR292（invokedynamicのサポート）もそのうちである。これは、静的に型づけされる言語であるJavaでは，ほとんど利用されないように思われるが、Method.invoke()が使われる際（例えば、RMIや他のエンタープライズ サーバ アプリケーションで）には、最適化に使うことができる。もしこれも、MethodHandle リテラルに対する言語サポートを含んでいるのなら、適切に名前のついたメッセージを見つけるのに、リフレクションを使う必要がなくなり、Javaクラス内でメソッドを使うのが，ずっと簡単になる。（ MethodHandle リテラルは、見えないところで invokedynamicを使うが、JLSに変更が必要である；なのでPlan Bでは、invokedynamicのVM 命令とMethodHandle クラスは、含まれるが、リテラルのサポートは，無いだろう）。
JVM上に代替言語を実装している人たちは、提案された予定変更に興奮している。invokedynamic が使えるのが、2012年まで遅れるより，早まるからである。（いずれにしても、ラムダ式などが2012年より早くなることはない。）JVM上でJRubyとMirahの両方を開発している Charles Nutter 氏は、その変更に冷静である:
メソッド ハンドルは、恐らく、私の開発にとって、JDK7の中で最も重要な変更です。単一メソッドのクラスを生成する際のオーバヘッド無しに（基本的に、*すべての*現在の」JVM言語は、一箇所か、他の場所でそうすることを強制されます）、関数や関数ポインタを表現したいと思う*すべての*JVM言語にとって、 メソッド ハンドルは、確かに重要な部分になります。しかし、それを長い間リリースできないなら、JRubyのような言語を実装するには、泥んこの中をとぼとぼ歩き続けるしかない、ということです。PermGenスペースが爆発しないように、いつも鋭いコードを生成する戦略を作りながらやるわけです（あるいは、単に余りにたくさんメモリを食わないようにします）。メソッド ハンドルがリリースに入るのが，早ければ早いほど、いいのですが。
なので、 Jigsaw, Lambda, と Coin を喜んで諦めましょうか？Jigsaw と Coin は，恐らくね。これらは、確かにリリースされません。ラムダ式に関しては，本当の関数型と、メソッド ハンドルと invokedynamicとの統合を短期間で「ちゃんと」できないなら、ちゃんとできるまで遅らせるべきです。そう言うのは、つらいですが、JVM上で、クロージャができる言語が他にあります。私が開発している JRuby や Mirah もそうです（ところで、Mirah は、*いかなる*ランタイム ライブラリ すなわち JVMのサポート無しに、 クロージャともっと多くを提供します）、そして、我々 JVM 「システム プログラマ」にとって、匿名インナークラスは、なお「非常にいいもの」です（JRuby のコードベースを見てください、我々は、それらを物凄く使っています）。
ああ、Scalaを得意げに話す皆さん、Plan Bから抜けてしまうフィーチャをScalaは，どうやって解決しているのか，どうか、私に説明願いたい。ええ、Scalaには、クロージャがありますが、他の言語や通常のJava コードとは、一般に相互操作できません（設計にかなりの制限をしなければ）、そのために、Scala 開発者以外には、クロージャは，役に立ちません。Jigsawのゴールに取り組むものは，皆無です。そして、Scalaでは提供している、Coinのほとんどのものは、（私が思うに）既にリリース レベルにあります。Scala は、JVMの共通語として、Java の代替では、ありませんし、これからも、そうはならないでしょう。
他の人達は、もっと早く、そしてリリース回数が、もっと頻繁にされるべきだ，と考えている。Java 6は、長い間使われているが、バージョン付けスキーマが、その間のVM中の重要な変更を隠している。 Osvaldo Pinali Doederlein 氏は、以下のように 書いている:
もちろん，理由は、JDK 6です。私は、常に「 6uNの後の」リリースを追いかけていますが、 Sun/Oracleは、いつも隠し続けています。自分たちのTCKをちゃんと通しながら、できる限り多くの改善を施しているわけです。私は、6u23の最初のビルドを既にテストしましたが、これは（たくさんのSwingの修正に加えて）たくさんのVMアップデートを施していて、今や開発最先端の HotSpot 19（現在のところ、JDK7からの最新版）になっています。この中には、有名なJDK7 のフィーチャである最新のG1 コレクタ、JSR-292の完全なVMサポート、そして64Gb ヒープでの CompressedOopsのような他の項目、CMSの修正、たくさんの小さなVM/ランタイムの修正と改善が含まれています。
バージョン ナンバーは、幾分任意なものです。Sunは、 J2SEJavaSEのバージョン スキーマを何回か変更しています。いつも世界の半数の人は、新しいスキーマを嫌います。ある人達は、6u10は、6.1と呼ばれるべきだ，と考えています。この場合、 6u14->6.2, 6u18->6.3, 6u21->6.4 そして 6u23->6.5 のようにバージョン番号を変えることになるでしょう。多分このほうがいいかもしれません：「やあー、JDK7が遅れる、最低だよ...しかし少なくとも6.5は、あるよ！」
遅れることの別の利点は、慌ててやるよりも物事がちゃんとやられることである。 Lambdaプロジェクトには、競合するゴールがあった。コア Javaライブラリ（例えば：ラムダ式を利用して、どうやって短い時間で、Collectionクラスを修正するのか）は、短い期間では、問題を起こすことになるだろう。Lambdaプロジェクトにもっと時間を与えれば、JDK7を止めること無しに、これらのことがJDK8と調和されるだろう。そればかりでなく、最新の提案では、完全にJavaでの関数型を排除している（以前，InfoQに載った）。もっと時間ができたことを考慮して、決定を再考する 要求がこれまであった。しかし、第一になぜそれらが除かれたかの理由が、はっきりしないので（型システムの問題なのか、時間が足りないのか）、それらが再び蘇るのかどうかも、はっきりしない。
JDKのモジュール システム化を狙った Jigsawについても同じことが言える。OSGiが、これまで長い間、Javaにおけるモジュール システムの標準であるのに，JigsawがJava言語ライブラリを分割する方法として、車輪の再発明をしようとしている。 Qwyltがこれら2つを統一しようとしているが、他のところで書かれているように、JVMとJava ライブラリは、本当に2つの違う目的を実行するものである。JVMをJava ライブラリから分離するPlan C は、誰にとっても、大きな利益をもたらすものである。そうすれば、ライブラリ（ IO, NIO, NNIO, NNNIOのような）は、それぞれのスピードで進化でき、今のように、JVM + ライブラリの組合せの特別なリリースに依存することがないようになる。
Peter Kriens 氏が書いている:
Java プラットフォームが大きければ、大きいほど良くなる、という誤解によって、Java は、徐々に壊されている。しかし、より大きくなるということは、より内部的な依存性が増すことを意味し、このような依存関係は、すぐにプラットフォームを複雑にするものである。ロープを持てば持つほど、絡み合いやすくなるのです。繰り返しスケジュールがズレるのが，その徴候の一つです。
モジュール化は、我々がケーキを持ち，食べることができる唯一のメカニズムです。もしJava がコアJava プラットフォームからできていたら、JSRの実装を別のモジュールとして、簡単に含むことができたでしょう。私は、決してSwing を使いません、じゃあ、なぜ私のプラットフォームにそれが入っているのですか？そして，もしそれを私が使うなら、別バージョンのものが必要です。JSRをモジュール化するのは、小さなアプリケーションのライフを恐らく，複雑にするでしょう。しかし、本格的なアプリケーションにとって、外部依存性を処理することは、すでに複雑なライフの一部になっています。複雑になる理由は、驚くことにJava は、これらの依存性を扱うことを全くサポートしないためです。
我々に必要なのは、最小限で、真のモジュール性理解しているコア プラットフォームです。すべてのjavax パッケージを含むのではなく、この最小限のJava は、よく定義されたコアパッケージ、と私のデスクトップマシンとサーバにライブラリやアプリケーションを追加するのが、簡単にできる（リモートの）レポジトリから、モジュールを適切に処理できる、メカニズムだけを持っているべきです。Perl は，それができますし、Ruby もできます。Python もできます。なぜJava は、同じことをするのにそんなに大変なのでしょうか？
我々は、技術を持ってます、必要な全てのパーツを持ってます。Oracle、どうか、この遅延が機会を与えてください。我々は、Java をまたアジャイルにすることができるか？
Oracle がJDK7 の以前に計画していたフィーチャのいくつかを、遅らせることを考えている、という短い発表で、彼らは、問題をPR用のクーデタに変えた。「早くリリース、頻繁にリリース」のアプローチを勇気づける多くのコメントが、Oracle がjavaOne で公式に遅れを発表し、そして、コミュニティが彼らに味方していることを言うよう、Oracle を促している。（もしOracle が遅れを Lambda-Devリストだけに、発表したら、遥かに大きなネガティブな反応と、より少ないポジティブな反応を得ることになったろう。）そうすることが、Java プラットフォームにとって、まだリリースレベルにないライブラリ（ラムダ式）を熟成し、必要かどうかを考える（Jigsaw) 時間ができる、という希望を与えることになる。一つ確かなのは；問題をオープンにすることによって、Oracle は、遂にコミュニティの意見の重要さを理解した、ということである。