先日、JJUGナイトセミナー「Java SE 10 / JDK10 リリース特集」に行ってきました。簡単に所感をまとめます。
メモから抜粋。(資料が公開されたら貼っておきます ⇒ 2018/03/29 追加しました)
JDKリリースモデル変更について
- 5/17 Java Day Tokyo 2018
- OpenJDK
- 無償提供
- GPLv2 + Classpath Exception
- 6ヶ月単位でリリース
- 3ヶ月単位でパッチリリース
- Oracle JDK
- ドキュメントは OpenJDK から提供される
- Deprecated の運用ルールはそのまま (1年で削除される)
JDK10の追加機能解説 - JEP286/ローカル変数の型省略(var記法)を中心に
JDK 10 へようこそ from David Buck
www.slideshare.net
- JEP 286
- ローカル変数の型推論
- 初期化のときに型宣言を省略して読み易くする
- ローカル変数は for ループ, for-each, try-with-resources を含む
- ローカル変数の型推論 != 動的型付け
- コンパイラの話でありランタイムレベルの話ではない
- 従来のコードが簡潔に書けるようになる
- 型が明確であれば読み辛くなることはないはず (もちろんすべてに当てはまるわけではない)
- なぜローカル変数だけなのか
- フィールドやメソッドの引数などの影響は複数のファイルにまたがるため
- Denotable types
- varが常に何らかの型でリプレースできるとは限らない
- varは型の名前には利用できない (Varは大丈夫)
- 変数名には利用できる
var var = new var();
- 書き易さより読み易さ
- ローカルコードで理解できることが大事 (どう動くか判断できること)
- IDEなどのツールに依存するべきではない
- 明示的に型を宣言するのはトレードオフ (すべてのローカル変数をvarにすることは避ける)
既存コードを一気に var に置換するとかは NG です。あと、原則やガイドラインは以下にまとまっています。とても重要。
個人的に興味深いのはこれ。これが問題になることはあまりないとは思いますが。
// ORIGINAL List<String> list = new ArrayList<>(); // Inferred type of list is ArrayList<String>. var list = new ArrayList<String>();
あと、おもしろかったのはこれ。
PriorityQueue<Item> itemQueue = new PriorityQueue<Item>(); // OK: both declare variables of type PriorityQueue<Item> PriorityQueue<Item> itemQueue = new PriorityQueue<>(); var itemQueue = new PriorityQueue<Item>(); // DANGEROUS: infers as PriorityQueue<Object> var itemQueue = new PriorityQueue<>(); // DANGEROUS: infers as List<Object> var list = List.of();
var とダイアモンド演算子を併用すると Object として型推論される模様。後日、同僚と話してたんですが、var とダイアモンド演算子を併用するときはコンパイルエラーにするとか、IDE で警告出すとかしてもよさそうですねという話になりました。
もう1つおもしろかったのはこれ。
// ORIGINAL byte flags = 0; short mask = 0x7fff; long base = 17; // DANGEROUS: all infer as int var flags = 0; var mask = 0x7fff; var base = 17;
たぶん32ビット以下の値が int として型推論される模様。
あと、きしださんのエントリ。
Java 10でぼくたちの生活は どうかわるの?
www.slideshare.net
- Java XX で動かしてみる
- Java XX でコンパイルしてみる
- jdeps や jdeprscan で内部APIか非推奨APIを使ってないか確認する
- jdeps : 依存関係を調べる
- jdeprscan : 非推奨APIを使ってないか
- Parallel Full GC は効果的だが、そもそも Full GC が頻発するような状況自体がよくない
- LTS のバージョンごとにアップデートするといきなり削除されている API が出てくるかも
- 基本的には
@Deprecated
でforRemoval=true
の API が将来的に削除される
- 基本的には
- immutable コレクションの確認/作成を自前でやってるところは標準 API の
copyOf
で置き換え推奨 - RuntimeMXBean でプロセスIDが取得できる
Java 9, 10 は Java 11 サポートに向けて検証するために利用するのがよさそうとのこと。Java 8 から 9 を乗り越えるのが大変っぽい。それ以降はそれほど大きな壁はないはず。