Devoxx開催中、Java SE Chief EngineerのMark Reinhold氏は、2010年上旬のリリース日を見越して、Java 7の最新の方向性についてプレゼンテーションを行った。Mark氏はこのプレゼンテーションを暫定案と表現し、決定事項ではないとしたが、コミュニティからは、特にクロージャの切り捨てに関して多くの反応が寄せられた。
Devoxxに出席したHamlet D'Arcy氏は、Java 7の機能に関するMark氏のプレゼンテーションのサマリを提供している(リンク)。同氏がまとめた、より重要な変更の一部を以下に紹介する。
モジュール化 – JSR 294とProject Jigsaw
JSR 292 – JVMによる動的言語のサポート
JSR 203 – より新しいI/O API。これは完成間近で、（単なるノンブロッキングI/Oではなく）完全非同期のI/Oを含み、最終的にはリアルファイルシステムAPIを実現。
JSR未定：若干の言語変更（以下に紹介）
Safe rethrow（安全な再スロー） - 広範なcatch節を可能にし、tryブロックからスローされたものに基づいて再スロー可能なものに関して、コンパイラがよりスマートとなる（これは今まで見たことがありませんでしたが、便利そうです）。
nullデリファレンス式 - 「?」シンタックスを使用したnullチェックはGroovyと同様で、開発者がnullチェックのネストを回避するのに役立つ。
より優れた型推論 - Genericsのインスタンス化に関連する例であるが、推論がどこまで行われるかは不明（私としては、多ければ多いほどよいと思います）。
Multi-catch - （これはうれしい！）catch節内でカンマ区切りの分離型の例外タイプリストを実現
以下は、Open JDKにおける活動で中心的な役割を果たしているJoe Darcy氏のブログ（http://blogs.sun.com/darcy）を参照した。
JSR 296 - Swing アプリケーションフレームワーク – これは、Swingアプリケーションを作成するためにより簡素化されるべき
6u10機能の転送ポート（Java Kernal、QUickstarter、新しいPlug-inなど）
また、同氏はJava向けに考案されたいくつかの機能についても言及しているが、これはおそらくバージョン7には含まれないだろう。
クロージャ – 単一の提案をめぐる合意なし
Reified generics（具象ジェネリクス）
最高クラスのプロパティ
Operator overloading（オペレータオーバーローディング）
BigDecimal シンタックス
JSR 295 - Beans Binding
Java.netでは、「Java 7から削られた機能のうち、どれに最も興味があったか」について投票を実施しているが、この記事の執筆時点では、クロージャが他の機能を引き離してトップとなっている(リンク)。
クロージャ 47.4% (734 Votes) 最高クラスのプロパティ 17.2% (266 Votes) First-class properties 10.4% (162 Votes) Operator overloading 4.3% (67 Votes) BigDecimal シンタックス 3.4% (54 Votes) JSR-295 Beans Binding 7.3% (113 Votes) どれにも興味なし 9.7% (150 Votes)
Ricky Clarkson氏は、クロージャがないならJavaは「死んだも同然」(リンク)と信じている。
これで確実です。James Gosling氏がクロージャを望んでも、3つのクロージャ用プロトタイプコンパイラが有効であっても、他のすべてのJVM言語がクロージャをサポートしていても、Java 7にはクロージャがないのです。
Martin Kneissl氏もまた、Java 7がクロージャを持たないことを悪いニュースだと感じている(リンク)。
Java 5で追加された新しいスタイルの「for」ループの代わりにクロージャを持つべきで、Java 6でクロージャを採用すべきでした。Java 7ではクロージャが用意されないようですから。
クロージャはそれほど理解が難しいものではありません。少なくとも、Javaにおける非同期の内部クラスと比較するときは。しかし、他の人々はこの意見に異を唱えます(リンク)。私は、クロージャ反対者の論理的思考、つまり、程度の低いJavaプログラマがいるから言語を制限してそれらプログラマが多くの被害を出すのを予防しているのだ、という意見に賛同できません。これはありえないことです。能力のないプログラマは、どんな言語であっても自ら災いを招くものです(リンク)。
幸い、JVM上には、ライブラリ、移植性、および（ある程度の）ツーリングというJavaの真の強みが使用できる言語が他にもあります。
Dustin Marx氏は、最も惜しまれたJava 7機能についての自身の投稿において、クロージャに対してもう少し相反する見解を示している(リンク)。
この記事の執筆時点で、実に160以上の投票があり（現在でもかなり早いペースで新しい投稿が増えていますが）、Java SE 7から切り捨てられた機能のうち、最も惜しまれたのは断トツでクロージャ(リンク)です。この時点で、クロージャ機能は、全体の投票数のほぼ半分を占めていました。ある意味では、これは想定されていたことです。クロージャ(リンク)は、Java SE 7(リンク)に含まれないと発表されるまで、Java SE 7(リンク)の議論の的であったようです。しかし、この重要な議論の一部の根拠は、クロージャを完全に持つコンセプトとクロージャ実装方法の両方をめぐって物議をかもしています(リンク) (リンク)。
クロージャ(リンク)はJava SE 7にとって最も熱く議論された提議の1つですが、私は個人的に、クロージャ対してはかなり相反する見解を持っています。クロージャが時として作業にどれだけ役立つかも理解できますが、多くの場合、クロージャなしでもすませられます(リンク)。言い換えれば、クロージャが追加されても構いませんが、Java SE 7に含まれないと聞いてもそれほど動揺はありませんでした。しかし、これまでの投票結果を信じるなら、Java開発者の半数近くがこの機能を一番に望んでいるのです。これは、開発者にJava SE 7までにクロージャ問題の解決を望むかを尋ねた (リンク).以前のJava.net投票質問と一致しています。
Osvaldo Doederlein氏は、新しい機能に胸を躍らせているが、それでもやはりクロージャがないことを物足りなく感じている(リンク)。
ForkJoin.Java 7はインフラストラクチャの点において、ここ何年もの中で最高レベルのリリースとなるでしょう。294/Jigsawと並行クラスローディングは、大規模アプリケーション、特にJava EEサーバーやIDEなどのマイクロカーネルベースのアプリケーションのブート時間を早めることができると思います。XRenderは、最終的にJavaをLinuxデスクトップアプリケーションにとって最高クラスの住民へと押し上げるでしょう。また、G1、フル64ビットサポート（実際には6u12でデビュー、ベータ版が入手可(リンク)）、ForkJoinなどがあります。
このように多くの優れた機能があり、おそらくクロージャが採用されないという悲しみはほとんど忘れることができます。私が思うに、（RubyやPythonなどの動的タイプのクズでなく）Scala、JavaFX、またはその他の近代的なJVM言語に移行する時がやってきたのです。今から5年後、もし私が低レベルのランタイムの類（ミドルウェアなど）を記述しているなら、「標準的な」Javaコードを記述しているだけだと思います。コミュニティの保守的傾向のおかげで、Java言語は、ゆっくりと過去の遺産および低レベルロールに移行しつつあります。
一方、Matt Grommes氏は、BigDecimalシンタックス(リンク)に注目している。
私は過去1年間、会計システムに関わってきましたが、BigDecimalシンタックスが非常に苦痛です。これについて心から不満を感じています。
Stephen Colebourne氏は、DevoxxとJavaEdgeの聴衆に、JDK 7について10個の可能な言語変更を提示し(リンク)、投票を行った。
明らかな勝者は、null処理です。null処理は、50の第一選好投票を獲得し、これは2位のString Switch（文字列スイッチ）の2倍で、すべての第一選好投票の約3分の1です。この傾向はトップ4のほぼ3分の2で続いていました。
人気のあったその他の選択肢は、String Switch、例外のMulti-catch、および強化されたMap用for-eachループ（インデックスとARM型のリソース管理の削除/発見を可能にするために強化されたfor-eachループ）です。
人気の低かった選択肢（特に、「悪いアイデア」という評価を受けたもの）は、[]を使用するList/Mapアクセスと文字列の補間（${variable} in strings）です。
Infer Generics（ジェネリクス型推論）とマルチライン文字列は、比較的重要性が低いと見なされましたが、特に反対されていませんでした。
ここで特筆すべきことは、Devoxxにおいてクロージャに関する投票が半々に分かれたことである。
次世代のJava SEプラットフォームに関する詳細については、ここInfoQで入手することができる(参考記事リンク)。