毎年お馴染みのリリース時期がやって参りました。
今回はとうとうメジャーバージョンが4へ上がっておりまして、
内部APIが刷新されているものの、
パッと見ではそんなに変わっておりませぬ。
ちなみに前回の分はこちら。
http://takahashikzn.hatenablog.com/entry/20110623/1308813250
早速、Mergedocで配布されているものをインストールして環境構築し、
使ってみたのですが…ビルドが遅い (´・ω・｀)
僕の環境では、ビルド完了までにEclipse3.7の5倍〜10倍程度の時間を要しています。
コンパイルはすぐ終わるのですが、各種バリデータの動作が非常に遅いようです。
業務で使用する際は、ご注意下さいませ。
では、以下のURLの適当日本語訳をどうぞ。
http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/news/eclipse-news-part2.html
リンク先には画像がいっぱいあるので、
それを見ながら読んだほうが理解が早いかと思います。
CamelCase in Quick Outline （クイックアウトラインでキャメルケースをサポート）
Ctrl+O（クイックアウトライン）やCtrl+T（クイック階層）で
キャメルケースをサポートしました。
『型を開く』やコードアシストのダイアログと同じノリで使えます。
もちろんワイルドカードも。
Quick Assist to convert enhanced for loop （クイックアシストで拡張forへ変換）
拡張for構文へさくっと変換するクイックアシストを使えるようになりました。
デフォルトキーバインドではCtrl+1で発動します。
また、（伝統の）カウンタを使ったforループや、
Iteratorを使ったループへ変換する機能もあるようです。
Improved bracket matching support in Java Editor（括弧のマッチングにまつわる改善）
現在のカーソル位置の、一つ外側の括弧を強調表示できるようになりました。
（例えば、メソッドのどこかにカーソルを置くと、メソッドの開始・終了の括弧を強調表示可能）
また、『対応する大括弧へ移動』アクション（Ctrl+Shift+P）を、
括弧の近傍にカーソルを置かなくても、いつでも発動できるようになりました。
連続して発動した際の動作としては、
- 一回目：最寄りの対応する括弧へ移動
- 二回目：ペアとなる括弧へ移動
- 三回目：最初のカーソル位置へ戻る
です。
で、カーソル位置の『近傍』の制約が緩くなり、
括弧の前後どちらにおいても判定できるようになりました。
（これまでは括弧の直前にカーソルを置かないとダメだった…ハズ）
あと、波括弧の開始位置付近のソースをホバーで表示できるようになりました。
長いコードブロックの場合、『この括弧ってどこに対応してるんだっけ？』を、
いちいちカーソルを戻さなくても確認できるようになったということです。
'*.class without source' file type（『対応するソースファイルがないクラスファイル』というファイルタイプを使用可能に）
対応するソースファイルがないクラスファイルを開いた場合に、
個別に関連付けを行えるようになりました。
ソースがない場合はデコンパイラで開く、という使い方を想定しています。
Default implementation for correction proposals（誤り訂正候補のデフォルト実装を追加）
クイックアシストやクイックフィックスで、
コードの誤りを訂正するための候補を表示するような機能を作る際、
その足場となるデフォルト実装が追加されました。
プラグインを開発する際などに楽ができるようです。
Content assist in package-info.java （package-info.javaでのコンテンツ・アシスト）
package-info.javaでコンテンツ・アシストが効くようになりました。
パッケージにつけるアノテーションをアシストするような使い方を想定しています。
ところで翻訳とは関係ないですが、
package-info.javaの便利な使い方パターンって有るのでしょうか。
現在は各人が自由に使っているような状況ですが、
使い方のパターンがあっても良いような気がします。
Selectively ignore errors/warnings from source folders （コンパイラのエラー・警告を無視するソースフォルダを指定可能に）
Javaコンパイラのエラー・警告を無視するフォルダを
個別に指定できるようになりました。
自動生成したコードやJUnitテストコードなど、
ある程度の雑音は無視して良いコード等を、
除外指定すると幸せになれるのではないでしょうか。
Enhanced diagnostics for detection of incomplete switch statements （不完全なswitch文についての解析精度の向上）
switch文の解析について、解析精度が向上したり、
設定できる内容が増えたりしています。
コンパイラは、次の2つの観点からswitch文を解析できるようになっています。
オプションで指定すると、Enumの値を全網羅していないswitch文において、
たとえdefault文があっても警告が出るように出来ます。
これにより、Enum定数を追加した際などに、case文の追加忘れを予防できます。
New options to detect resource leaks （リソースリーク検知が可能に）
コンパイラでリソースリークを検知できるようになりました。
具体的には、ローカル変数でjava.lang.AutoCloseableまたはjava.io.Closeableを使っていて、
同一スコープ内でクローズしていない場合、警告が出るようになります。
そして、『潜在的リークを検知』というのも追加されていまして、これは
close()が呼ばれないパスが存在しないかどうか検査するというものです。
要するに、close()がif文の中に入ってしまっている等で、
状況によってはそれがスキップされてしまう可能性が無いか検査するということです。
この『潜在的リーク検知』、リソースがメソッド間で共有されている場合においても、
うまいこと判定してくれるらしいです。
例えばメソッドの引数でリソースを渡した場合は、
実行パスを見てくれる（『潜在的リークを検知』する）のですが、
インスタンスフィールドとして保持しているリソースの場合、
クローズを呼ばなくても良しとするという調整が行われています。
（そういう仕様のプログラムを書くケースが実際にある為）
また、実際はリソースリークにならないケースも認識できるようです。
例えばStringReaderやByteArrayOutputStreamなどは、
実際はクローズする必要が無いものです。
そういう輩は検知対象外にしてくれます。
具体的にどういうケースが当てはまるかはリンク先を参照するように（手抜き）。
New Batch compiler warning options （バッチコンパイラの警告オプション）
バッチコンパイラ（訳注：コマンドラインコンパイラ、つまりecjのことだと思う）の
警告オプションが追加になってます。
- warn:all→すべての警告オプションをONにする
- warn:resource→リソースリーク関係の警告オプションをONにする
New build path option to warn when a source folder's output location overlaps another source folder（コンパイル結果の出力先が別のソースフォルダだった場合に警告）
タイトル通り。
（…こんな間違いをする人がいるのか？）
Annotation-based null analysis（宣言ベースのnull解析）
アノテーションを使って宣言的にプログラミングすることで、null解析ができるようになりました。
ま、詳しくはリンク先の画像を確認すれば一発でわかると思いますが…（手抜きパート2）
org.eclipse.jdt.annotationパッケージの@Nullableや@NonNullをメソッドの
メソッドの引数や戻り値に付けまくっておけば、後はコンパイラがヨロシクやってくれます。
但しこの機能、初回リリースにつき、
多少不自由が残っているけどそれは許してね、とのこと。
そういやGoogleも似たようなモノを出してますよね、コレ。
Batch compiler options for using null anotations （null解析に関連するバッチコンパイラのオプション）
引数のwarnオプションにnullAnnotを渡すと、null解析が発動します。
アグレッシブに行きたい気分の時は、-nonNullByDefaultを指定すると
NonNullが全ての箇所で指定されているように振る舞います。
ま、山ほど警告が出ると思いますが…
Detection of missing default nullness annotation（null解析に関する指定がきちんとされているか検査）
アグレッシブに行きたいアナタ向けの機能ですが、
全てのパッケージでNonNullByDefaultの指定があるかチェックできます。
これは要するに、全ての要素についてNonNullなのかNullableなのかを
指定済みであることをチェックできるということです。
Null analysis treats org.eclipse.core.runtime.Assert like Java assert （Eclipseのアサーション機構をJavaのassert文と同様に）
null解析について、EclipseのAssertを使っても、
javaのassert文同様の解釈を行うようになりました。
例えば、
Object p = foo();
assert p!= null;
p.wait();
というコードにおいて、
従来のEclipseはpがnon-nullであると判断する機能を持っています。
これをEclipseのAssert機能を使った場合でも適用するように拡張したということです。
たぶん。
