http://openjdk.java.net/jeps/213 をテキトーに訳した。
JDK 9リリース予定のものなので、将来的に2014/10/28時点の自分の翻訳は古くなっている可能性があります。最新の情報が必要な場合は、リンク先を参照してください。
JEP 213: Milling Project Coin*1
Author Joseph D. Darcy Owner Joe Darcy Created 2014/05/09 23:05 Updated 2014/10/23 22:06 Type Feature Status Proposed to Target Component tools / javac Scope SE Discussion compiler dash dev at openjdk dot java dot net Effort S Duration M Priority 2 Reviewed by Brian Goetz Endorsed by Brian Goetz Release 9 Issue 8042880 Relates to 8061549: Complete the removal of underscore from the set of legal identifier names 7196163: Project Coin: Allow effectively final variables to be used as resources in try-with-resources 7196160: Project Coin: allow @SafeVarargs on private methods 8058519: Project Coin: Explore allowing interaction of diamond syntax and inner classes
Summary
JDK 7 / Java SE 7の一部であるProject Coin / JSR 334の小規模な言語変更は、現実的には良い改良となり使い勝手を向上させました。しかしながら、変更箇所のよろしくない点*2に取り組むいくつかの修正案が出されています。加えて、識別子としてアンダースコア（"_"）を使用するとJava SE 8では警告が出る点は、Java SE 9ではエラーにすべきです。
Non-goals
このJEPは、"Coin 2.0"プロジェクトの始動や、新しい言語を要求したりする提案ではありません。
Description
Javaプログラミング言語に対する4つの修正案を提案します。
- privateなインスタンスメソッドに@SafeVarargsを付与可能にする。
@SafeVarargsアノテーションは、staticメソッドやfinalなインスタンスメソッドなどの、オーバーライド不能なメソッドにのみ適用可能です。privateなインスタンスメソッドは@SafeVargsが適用できてもよいハズの使い方の一つです。 - try-with-resourcesのリソースとしてeffectively-final変数を使用可能にする*3。Java SE 7のtry-with-resourcesの最終バージョンでは、try-with-resourcesが管理する各リソースは新規の変数(fresh variable)として宣言する必要があります。これは機能の早期イテレーション以降に変更されています。public review draft of JSR 334では、try-with-resource管理下で式を許可するearly draft reviewバージョンからの変更理由について述べています。JSR 334エキスパートグループはtry-with-resourceに対する追加改修を支持しています。その内容は、リソースがfinalもしくはeffectively final変数で参照される場合、 try-with-resourcesは新しい変数を宣言することなくリソースを管理可能にします。このtry-with-resourceが管理する制限付きの式は、汎用的な式サポート*4の削除原因となった、意味の問題(semantic issues)を回避するものです。エキスパートがこの修正を決定した当時、リリーススケジュールに変更を調整するほどの余裕がありませんでした。
- 引数の型に型推論が可能なら内部クラスでダイアモンドを使用可能にする。内部クラスのコンストラクタでのダイアモンドによる型推論は、シグネチャ属性がサポートする型セットから外れる可能性があるので、Java SE 7では内部クラスでのダイアモンドは許可されていません。JSR 334 proposed final draftにある通り、もし型推論が可能であれば*5、この制約は緩和が可能です。
- Java SE 8から開始された、妥当な識別子名*6からアンダースコアを削除をする作業を完全に終わらせます。
Java言語に対する変更の歴史において、こうした改修は小規模な変更に留まります。@SafeVaragsの変更は仕様の1,2行を修正するだけで、javacの修正も似たような大きさになります。しかし、すべてのJava言語に対する修正と同様に、こうした改修には更新を必要とするプラットフォームのすべてを取り扱う慎重さが必要です。
Testing
言語の変更には通常javacのユニットおよびリグレッションテストが要求されます。JCKコンパイラースイートのポジティブテスト・ネガティブテストの両方とも修正が必要です。
effectively-finalについての補足
effectively-finalは"実質的なfinal"といったところ。http://stackoverflow.com/questions/20938095/difference-between-final-and-effectively-final や http://docs.oracle.com/javase/tutorial/java/javaOO/localclasses.html#accessing-members-of-an-enclosing-class を参照。以下はThe Java Tutorialsからの抜粋で、「effectively finalとは、初期化後に決して変更されない変数や引数のことです」とある。
A variable or parameter whose value is never changed after it is initialized is effectively final.
*1:millingとは http://ejje.weblio.jp/content/milling によると「(貨幣の周囲の)ぎざぎざ(をつけること)」という意味がある。小規模変更のProject Coinに更に細かい変更を加えるイメージと思われる。ミリングマシンでググればどんなことするブツなのかイメージつくかと。
*2:a few rough edgesが原文。http://idioms.thefreedictionary.com/rough+edges によると、結果や働きぶりの品質がアンマリよろしくないことを指すイディオムだそうで。
*3:補足参照
*4:general expression supportが原文。詳細はリンク先とかぐぐって欲しいが、元々はtryに式が使えたりともっと汎用的な代物だったらしい
*5:if the inferred type was denotableが原文。denotableが上手く訳せなかったので「可能であれば」にしてしまった。
*6:原文はlegal identifier names.legalって日本語では何にすべきだろうか……
