Java 7における5つ(かそこいら)の変更点確定版
Java 7の最終変更点が確定したとのことで、記事を翻訳してみました。
Project Coin: The Final Five (Or So)
まず最初に、Project Coinへ興味深い提案をお送りいただいたみなさま、思慮深いコメントをくださった方々、そしてJavaプログラミング言語を発展せしめんと欲するまさしく活力のあるコミュニティの皆様にお礼申し上げます。
これ以上の波乱もなく、JDK7に含められることが決定した最終的なProject Coinの変更は以下の通りです。
- Switch文中での文字列の使用
- 自動的なリソース管理
- ジェネリックなインスタンス生成のための型推論の改善(ダイアモンド ※注1)
- 単純化された可変引数メソッドの呼び出し
- より良い整数型リテラルのための、オムニバス提案(多くを含んだ包括的な提案)
- コレクションのための言語サポート
- JSR292のための言語サポート
相互作用が吟味されて、問題が明確になるまでは、これらの変更に対する仕様と実装、そしてテストは最終的なものにはならず、発展し続けるでしょう。これらのリストのアイテムのうちの２つは、送られてきた複数提案の組み合わせです。
整数リテラルの改善に関するオムニバス提案は、少なくとも「二進数リテラル」と「数値中の下線」を含みます。符号無しのリテラルをより良く扱うための方法も求められています。コレクションのための言語サポートは、コレクションのリテラルとリストとマップに対する添字アクセスを含みます。技術的問題が解決されることが前提ですが。
最終リストでは受理しなかったけれども、さらなる検討を続けることになった2〜3の提案も残されています。
例外ハンドリングの改善は、言語に取っては良い変更ですが、型システムに対しての際どい冒険になるでしょう。なので、JDK 7に間に合うように十分に開発リソースを割けないだろう、と思っています。今後の検討で、言語を発展させるような、より優れた例外ハンドリングが再考されて欲しいと思っています。
エルビス演算子と関連する演算子はGroovyでは役に立つのですが、GroovyとJavaの違い、たとえばプリミティブ型の存在や、boxing/unboxingの相互作用は、Javaの場合にこれらの演算子をやや不便にしてしまうのです。Java 7は他のやり方、JSR308で可能となるnullチェックのようなやりかたで、nullハンドリングの苦痛を和らげてくれるでしょう。
32ビット範囲以上のエントリの大きさの集合型のネイティブサポートが今後ますます重要になっていくことに疑いはありません。コレクションに対する言語サポートは、プラットフォームが直接大量データを扱えるようになるまでは、その機能をライブラリとして開発できるようにします。
coin-devのメーリングリストは、受理された変更のリファインを続けられるように、利用可能なままにしておきます。選択されなかった提案に対するさらなる議論は、このメーリングリストではオフトピックとなります。
Project Coinの変更の実装の対部分は、2009年10月末までにJDK 7のMercurial開発リポジトリに入るはずです。
そのうちに、Project Coinの変更点をカバーする範囲は、１つのJSRとしてまとめるつもりです。
(2009-08-28 17:45:48.0)
エルビス演算子、セーフナビゲーションは入らなさそう。
「自動的なリソース管理」は、Groovyではクロージャを使ってやる、ローンパターンの代替だね。クロージャ無くなっちゃったからね。
Java7に関して、前に翻訳した記事もどうぞ。
(2009/9/2追記)コメント欄で指摘を受け、「型インターフェース」を「型推論」に修正しました。
(2009/9/2追記)（※注１）ダイアモンドとは、リンク先を読むと、ジェネリック型のnewで、変数の宣言にジェネリクス指定しておけば、右辺は<>（ダイヤ型）で済むということのようです。例：Map
