JSR 308 (Annotations on Java Types)(source)は、先週のJavaOneプレゼンテーションでも重要な位置を占めており、Java SE7で提案されている新しい言語機能である("TS-5581: Javaプログラミング言語にもたらされる変更")(source)。改善されたcatch句（複数catch）(source) 、安全な例外再スロー(source) 、Javaモジュール(source) と言った他の新しい言語機能も、Alex Buckley(source) (Sun Microsystems), Michael Ernst(source) (MIT) and Neal Gafter (source)(Google)と言ったプレゼンターによってカバーされていた。
JSR 308は、現在Java 1.5アノテーション(source)に存在する二つの問題を解決しようと試みる物である。
- アノテーションの文法的な制限: アノテーションは、宣言部にしか記述できない
- 型システムの意味的な制限: 型システムは、バグを十分に防ぐことはできない
JSR 308によって提供される、これらの問題に対する解決策は以下のような物である。
言語のシンタックスを拡張し、より多くの場所にアノテーションを許容する メソッドのレシーバ、ジェネリック型引数、配列、型キャスト、型のテスト、オブジェクトの生成、型パラメータの束縛、クラス継承、throws節などを含む。
よりパラフルなアノテーションプロセッサの作成を可能に プラガブルな型システム(source)を通じて、これを実現する。型を修飾するアノテーションを付与されたコードは、型チェッカによって分析され、違反（バグ）について警告することができる。
このプレゼンテーションを受けて、Michael Nygard(source)はWhen Should You Jump? JSR 308. That's When(source) と言うエントリでJSR 308について書いている。このエントリは、JSR 308が言語とJava開発者に与える衝撃について彼の見解を述べたものである。これらのアノテーョンがどのように使われうるかについていくつかの例を示した後、このJSRはJava 1.5から導入されたジェネリックスと並んで、多少の利便性と引き換えに言語をより複雑にするとNygardは論じている。
あらゆる言語は複雑さの予算(source) を持ちます（訳注: ここで言う「予算」とは、メリットとデメリットのバランスをよく検討してから新しい機能を導入すべき、と言うこと）。JavaはそれをJava 5におけるジェネリクスで吹き飛ばしてしまいました。さあ、このコードをもう一度まじめに見直してみましょう。
@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>
これでもまだJavaに見えますか？複雑さの予算なんて、ここではほとんど考慮されてはいません。直訳すると、「バックミラーについた薄い染みに過ぎない」 -Shumpei 5/18/08 11:29 AM 私たちはコンパイラの幸せを保つことに忙しく、実際に予算を見積もることを完全に忘れてしまっています。
さらにこの新しい提案はタイミングが非常に悪く、開発者の興味を動的言語に向かわせることになる、Nygardと見ている。
Java言語にとっては考えうる限り最悪な時期に、これらの変更がもたらされます。コミュニティは本当に、本当に動的言語にエキサイトしているのです。このねじくれたコードの代わりに、単にこのように書くことができるのです。
var strings = ["one", "two"];
さあ真剣に考えてください、あなたはどちらを書きたいですか？確かに動的なバージョンは私に対して、コンパイラによる強制力で助けてはくれません。確かに、動的なコードに対してはより多くの単体テストを必要とします。しかし私は、"儀式めいたことの少ない"アプローチの方が、上の形式的で長ったらしいやつよりは好きです。
JSR 308が言語の一部になったときが、Java開発者が新しい言語に飛び込むべきときだとNygardは信じており、こうまとめている。
そう、メインストリームのJava開発者に戻るには・・・二つの選択肢しかないように見えます: より動的か、より静的かです。よりフォーマルで厳密、もしくはよりリラックスして簡潔か、です。JSR 308はこの対立をものすごく先鋭化させるでしょう。.
当然だが、この見解に対しては様々なコメンテーター(source)からの多くの反応が得られした。これらのアノテーションは便利な抜け道であり、APIドキュメントを読んだり、今何をしている最中かを考えなくて済むようになる、と見ている他のコメンテーターに応じて、cfaganは以下のように述べている。
最終的なコードこそが究極のドキュメントです。これらのアノテーションは、「意図を表現する」と言うことを試みています。プログラムの意図は、最新に保たれていないドキュメントやドキュメントの紛失とともに失われうる物です。私は、優れた才能のある人は、言語とは関係なく優れた結果を出すと言うのには賛成です。しかし、ランタイムエラーがコンパイル時に判明することで、開発プロセスのスピードは向上し、テストしなければ見つからないようなバグのオーバーヘッドを節約します。
Josefはこれらのアノテーションがオプショナルな性質を持つことについて書いており(source)、それらが役立つようになるまでの道筋について、彼の意見を披露した。彼はNygardに反論している。
... この著者は、JSR 308で使えるようになるアノテーションは強制的で、全てのJavaプログラマはJSR 308が承認されると、間もなくそれらを書かなければならなくなる、と言っているようです。私は、最初にそれらのアノテーションを使うJava開発者は非常に少ないだろう予想しています。それは非常に高いレベルの保証が必要なソフトウェアを書いており、正確な状態を指定するためにこうしたものを必要とし、それらが自動的・反自動的にチェックされることを望んでいる企業です。
そして、それらがジェネリクスとどう異なるのかについても説明した。
これらのアノテーションのいい点は、常に安全に無視することができる、と言うことです。もちろん、それはジェネリクスではできません。なぜなら、あなたのプログラムが持つ型を知らない、と言うことになってしまうからです。しかしJSR 308アノテーションでは、それらに全く注意を払うことなくコードを書くことができます。それらと関わりが生じるのは、あなたが実際にアノテーションに関心を持ち、チェッカーを使い始めたときなのです。
セッション"Javaプログラミング言語にもたらされる変更"のプレゼンターたちは、Java言語に加えられる新しい機能がどのように評価されるかについて、主な原則をまとめている。
- ハイレベルなプラクティスを促進すること（正しいことを行え）
- 明瞭さが望まれること（物事を正しく行え）
- 静的な型付けを好むこと（安全であれ）
- 言語とAPIを分離すること（抽象的であれ）
こうした原則に則ってみると、Java言語の全体的な方向性とJSR 308は、よく合致しているように見える。この新しい機能を追加することに関する最近の議論は、こうした原則の解釈が分かれていることを示す典型的な事例なのだろうか。それとも、世話役たちによってすすめられているJava言語の進化、それを導く原則自体に対して発されている警告なのだろうか？