Oracleは、Java 7/8の包括的なJSRを発表した。以前からPlan Bとして知られている、いくつものフィーチャがその中にある。JavaSEとJavaEEの仕様が定義される方法は、新しい内容を直接定義するのではなく、他のJSRを参照する方法をとる。しかしよく、参照されるJSRが完成した後で、そうするのである。今回は、参照される多くのJSRは、未だ作業中、あるいはモジュール化の件もあり、現段階では、わからないものもある。
JSR 336, Java 7は、以下のものを含むことを提案している。
- JSR 203, Javaの新々IO API
- JSR 292, JVMへの
invokedynamicの導入（メソッド ハンドルではない） - JSR 334,Project Coin, としても知られており、恐らく含まれるのは、
- switch文での文字列,
switch文で文字列リテラルが使える - バイナリ リテラルと数値リテラルでのアンダースコア が使えるのでソースコード中に 0b0100 や 1_234_5678 が使える
- マルチcatch,１つの
catchブロックで複数の例外タイプが扱えるようになる - ジェネリック生成のためのダイヤモンド オペレータ, ジェネリックなアサインメントの型をインスタンス化するジェネリック型から推論できるようにする
- リソース付きのtry, 自動的に「リソース」（
AutoCloseableを実装するもので、IOストリームを含む）をクローズする手段を提供する - varargs ワーニング, ヒープを汚すようなvarargsが起きた場合に警告を与える
- switch文での文字列,
しかし、これらは単に提案である。JSRの幹部は、「最終的なJava SE 7 プラットフォーム仕様は、これら全てのJSRを含まないかもしれないし、ここにないJSRを含むかもしれない」と言っている。リストには、追加がありえるので、JVMの一般的なJSR（JSR 294) やJava言語(JSR 901)に影響するだろう。このリストには、いくつかの保守レビューや新しいフィーチャもある。例えば、Nimbus ルック アンド フィール や JDBC 4.1である。後者は、データベース接続用のAutoCloseableをサポートする。 Alex Miller氏が書いているように、ありゃ、これは全JSRだ！
JSR 337, Java 8 がサポートするのは、
- JSR 308, Javaの型に対するアノテーション、（ジェネリックな変数のような）他の場所に存在する アノテーションを認める。面白いのは、このJSRは、活動しておらず、2007年からアップデートされていない。
- JSR 310, Stephen Colebourne氏によって提案されている修正された Date と Time API
- JSR 335, あるいは、Java言語の Lambda式（全てがクロージャなわけではない！）
- JSR TBD: Project Coin の残り、Java 7に含まれなかったもの
- JSR TBD: Java プラットフォームのモジュール システム
Java 8で面白いのは、これらのいくつかは、作業していないばかりでなく、提案されていないものもあることである。存在しないJSRに依存する、不確定なJSRに投票できる、とメンバーは思ってしまうだろう。おそらくOracleは、投票で気分良くさせて、Java 8 の方向 に関するEclipse側の意見をはぐらかして、投票の後でその内容を変えようとしているようである。面白いことに、IBMの最近の動きによって、Java 8のモジュール化に関して、Oracleは次のようなことを加えることになったのかもしれない。
提案されているJava プラットフォームのモジュール システムに関して、Javaコミュニティは既に、OSGi サービス プラットフォームのモジュール層を使って、アプリケーションやフレームワークを作るのに、相当な投資を行ってきたことは、理解しています。Java プラットフォームのモジュール システムがOSGi を採用する、相互運用できる範囲、あるいは、OSGiを受け入れるかは、 JSRの専門家グループと Java SE 8の専門家グループが議論し、決定するテーマとなるでしょう。
分析の全てが肯定的なわけではない。Stephen Colebourne氏は、TCKのライセンシングに関して詳細に調べている TCKのライセンスは、ここにある。
「製品」の定義には、普通には無いような部分（ハイライト部分）が含まれている。「製品」は、基本的な基準の他に3つの基準を満足しなければならない。
- "この仕様のスタンドアローンの実装とは、本質的に違う主要な目的を持っていること"
- "この仕様のスタンドアローンの実装よりも著しく、機能面と価値において強化されていることを示すこと"
- "この仕様のスタンドアローンの実装の置き換えあるいは、代替の技術として出荷されていないこと"
私は、Apache Harmony は、これらのテストの3つ全てに不合格する、と信ずる（このJSRを実装しようとして、恐らくできないであろうプロジェクトだった）。「スタンドアローンの実装」とは、 OpenJDK/OracleJDKであろうから、 Harmonyの第一の目的は、明らかに同じものであり（本質的に違うものでない）、Harmonyは、著しく機能面での強化を提供していないし、 OpenJDK/OracleJDKの代替として出荷されている。
彼は、Javaシステムは、Oracle以外の人間には実装できない、という見解で次のように結論づけている。
正直言って、Java SE 7のTCKライセンスが今だに、Oracle以外の誰でもオープンソースで実装できる、という嘘を含んでいるのには、驚きます。少なくとも制約は明らかです（私は思うのは、証明はできませんが、Sun/Oracle 対 Harmonyの論争で Java SE 5に対して、大変似たような制約が課せられています）。TCKライセンスは、JSRと矛盾します！JSR自身は、次のように言ってます。
そうなんです、JSRは、組込み環境をターゲットにしているのです。それは、TCKライセンスが言っているのとは、違う。 ;-)2.2 Javaプラットフォームのターゲットは何か？（すなわち、デスクトップ、サーバー、個人向け、組込み、カードなど）
このJSRは、組込み, デスクトップ、サーバーそしてクラウド環境をターゲットにしたJava SE プラットフォームのリリースを定義している。（ Stephen氏のハイライト）
この時点では、Apacheは、おそらくJava JSRの投票で象徴的に「ノー」と言うでしょう（ 彼らが言語への技術的な寄与をしたことへの同意として、 Project Coin と Project Lambdaには、おそらく賛成票を投じるでしょうけど）。しかし、他のJCPメンバーは、同じことはしないでしょう。その点に関して、Apacheは、辞任の脅かしをかけ続けるだろう