Sun Microsystems社のMark Reinhold氏はOpenJDKのウェブサイト上に、承認済み仕様(サイト)のリストと共にJDK 7の最新スケジュール(サイト)を公表した。現在のビルドは新しいGarbage First Garbage CollectorやI/O APIを含んだマイルストーン2である（JSR 203）。5月のJavaOneカンファレンスに間に合うことが期待されているマイルストーン3では、invokedynamicバイトコード命令を介した動的型付け言語のため仮想マシンサポートを追加する（JSR 292）。Java 7で計画されている注目すべきものはそのほか、OpenJDKでのJava 6 update 10（6u10）の転送ポート（マイルストーン4をターゲットにしている）、この秋に予想されているマイルストーン5、そしてJSR 294とProject Jigsawを通したモジュール化の標準化についての新たな試みなどがある。現在のロードマップにないもので目立つのは、新しいDate and Time API（JSR 310）、Beans Validation（JSR 303）、Beans Binding（JSR 295）である
小さな言語変更の構想であるProject Coin(サイト)も数多くの提案を行い、Joseph Darcy氏は彼のブログ(ブログ)で、Java 7への6つの有力な導入候補を強調している。
- 自動リソース管理。ARMブロックが、1つ以上のリソースがそのステートメントに限定されることを宣言するtryステートメントの形をとるもので、Joshua Bloch氏が提案している。ステートメントがコンプリートすると、正常であろうが突然であろうが、その全てのリソースが自動的にクローズする。これにより、実際問題としてエラーを起こしがちなことが知られている手動によるリソースのクローズをする必要がなくなる。Bloch氏によると、JDKのクローズ・メソッド使用の3分の2が誤って実装されている。
- Elvisおよびその他のnull安全な演算子。もともとの提唱はNeal Gafter氏のもので、そこからStephen Colebourne氏が提案した。これはNullPointerExceptionsの一般的な問題の一部を解決することを目的にしており、オブジェクト上でのnullチェック省略を可能とする。
- 例外処理の改善。Neal Gafter氏が提案しており、この提案には、複数の例外タイプと再スローされた例外のチェックを処理するcatchブロックが含まれている。
- ジェネリック・インスタンス生成のためのタイプ推測の改善。Jeremy Manson氏が提案。この提案では、クラス・インスタンス生成式のための限定タイプ推測の追加に取り組んでいる。例えば、記述する代わりにMapを使う。
- 可変引数メソッド呼び出しの簡素化。Bob Lee氏の提案で、これはメソッドが可変引数をnon-reifiableな配列型と結びつける際に発行される警告に対するコンパイラ変更である。この変更により、警告はコール・サイトからメソッドへ移動される。
- switchステートメントでの文字列。Joseph Darcy氏の提案では、switchステートメントでの文字列のサポートが追加されている。
Sun社のJava 7向けJDKは、その実装は依然として一部のクローズド・ソース・コンポーネントに左右されるが、初めてOpenJDKをベースとしたものになる。またJSRなしでの開発件数の増加と、それが完成した際に標準となることに伴い、Sun社がJava製品を開発する方法においても変化が起こり続けている。Project Jigsaw、JavaFX、そしてJava SE 7は全てこのように開発されたものである。Mark Reinhold氏はこのことについて以下のように説明している(サイト)。
「JDK 7プロジェクトはJava SE 7 Platform Specificationが行き着く可能性がある（あるいはないかもしれない）もののプロトタイプを作り出しています。SE 7 Platform JSRが提起されると、仮想マシン・レベルのものや実装特有のものを除きJDK 7で開発中の仕様がその中に含まれるよう提案されるでしょう。」
トランスペアレントな仕様のセットを伴うOpenJDKプロジェクトとJava 7のスケジュールの組み合わせは、以前の言語改定で遭遇したどのプロセスよりも極めてオープンなものだが、ApacheのStephen Colebourne氏はこの変更についてひどく懸念(サイト)しており、Java 7の公式な仕様があろうはずもなく、それどころかSun社のJDK実装のみであろうと唱えている。
「私が出会う全ての証拠は、Java SEはもはやオープン・スタンダードではなく、次回リリースはJava 7ではなくJDK 7である、というものです。これは、Javaのエコ・システムに関心がある全ての人々にとって重要になってくる事柄です。
結局、Sun社がオープン・スタンダードではないJava SE作成をうまくやり遂げることができるならば、Java EEやServlets、あるいはJMSもそうならないわけはないでしょう。今こそ堂々と意見を述べ、私達のオープン・スタンダードを取り戻すよう要求するときです！」
追加の投稿 (サイト)でColebourne氏はJCPエグゼクティブ・コミッティのミーティングメモを用いて彼の主張を裏付けており、プロセス変更の理由は、ApacheがそのHarmonyプロジェクトのために求めたJava Compatibility Kit（JCK）のライセンス規約の変更をめぐるSun社とApacheの長期的な論争に結び付けられるとしている。
「…2008年9月の会合から、Harmony論争が解決するまでJava SE 7 JSRを成立させることはできないとSun社が感じている明らかな証拠（ただし客観的な確証ではない）があります。また2008年4月と、Java SE 7プラットフォームJSRが「即時」から「直ちに行われるプランではない」に変更されSun社の焦点がJSRではなくOpen JDK使用にあると明らかになった2008年6月では、傾向に違いがあることを指摘できます。」
Neil Bartlett氏はColebourne氏の議論を支持している。Project JigsawではなくOSGi使用の理由として保留になっているSun社の買収の噂を用い、JSRが支持していないSun主導のいかなる構想も、Sun社が買収されるその瞬間に葬られる可能性があると論じている(サイト)。
「Sun社が来年のこの時期までに現在の形態で存在しているとは考えにくいでしょう。丸ごとIBM社に吸収されるか、半分に分かれてHP社とOracle社とで分配されるか、あるいは他に噂されている結果のどれかになるかにかかわらず、JigsawをサポートするというSun社の約束は全く役に立ちません。Jigsawは全ての買収候補の商業的ニーズの対極にあるので、これは特にそうなのです。IBM社がJavaを手に入れれば、彼らはJigsawを消し去るであろうことは私が保証します。Oracle社も同様です。JigsawをJSRの外で、そして既存の業界標準に対抗して構築することにより、Sun社はその顧客を相当な商業的リスクにさらしてきたのです。」
Sun社の議論が継続している一方で全てのJSRに反対票を投じるApacheの戦略は、他のJCPメンバからは限定的な支持しか得られていないので、これまでのところ実際にはJava開発に影響を与えていない。これはおそらく他のJSRは同じライセンス規約から影響を受けないためだ。しかし、Java SE 7は直に影響を受けるだろう。Apacheの策によりSun社はJava 7の開発方法を変えたというColebourne氏の推測が正しければ、これらの戦略および両者ともに妥協しないことが組み合わさり、JavaとJCPに甚大な被害を与え始めるだろう。