Java9勘所集

#Java9
2017/09/21(※米時間)リリース。
「※米時間」って米米CLUB思い出しません？
今「米米CLUB」って一発変換できたぞなんだこれ。

##変更一覧
[JDK9 Features](http://openjdk.java.net/projects/jdk9/)

###多い

##着眼点
1. インパクト
    - ソースを弄らなくてもリリース済みのブツに影響を与えるようなヤツ
    - これからの設計、コーディングに影響を与えるようなヤツ
2. 趣味
    - なんかVM近辺に影響してるヤツ

##抽出
###[Jigsaw系のヤツ](http://openjdk.java.net/jeps/200)
もう一杯情報出てるので細かくいうことはないですが、あのパッケージ関連グラフ見ると「ウッ」ってなりますね

###[jshell](http://openjdk.java.net/jeps/222)
もう一杯(ry

###String周りのヤツ
####[Compact Strings](http://openjdk.java.net/jeps/254)
- Latin-1(アルファベットとアラビア数字、半角記号辺り)の時を特殊化してメモリ削減！
- って言ってたけど、それマルチバイト文字圏だと逆効果じゃね？
- 詳細はこちらで詳しく　→　[Java9 でも String クラスがリファクタリングされていました （JEP 254: Compact Strings 編）](http://d.hatena.ne.jp/chiheisen/20170921/1506021860)
    + マルチバイト文字が入ると新しくメモリ空間を用意するもよう、Stringはイミュータブルだからまぁ、良いのか……？
    + EAだけどこんな結果もある模様　→　[Java9で文字列の結合の速度を確認する](https://qiita.com/deaf_tadashi/items/73b9d4ecbfe6f8b14e8f)
        + 2017/10/03 added ご本人から正式版の確認結果をご連携いただきました　→　[正式版Java9で文字列の結合の速度を確認する](http://tadashi.hatenablog.com/entry/2017/09/23/200356)
    + ~~なんか怪しいのでいずれ検証してみよう~~
        + 2017/10/03 modified
        + なんか「自分の認識が」怪しいのでいずれ検証してみよう
        + deaf_tadashiさんの検証結果が怪しい、と捉えられる文体だったので修正

####[Indify String Concatenation](http://openjdk.java.net/jeps/280)
- `"str" + "ing"`のやり方をInvoke dynamic命令を使用するようにして改善
- 過去もろもろあったStringBuffer→StringBuilderの経緯とかを気にしなくてもよくなるように
- これからの時代、何でもかんでも「StringBuilderを使え！」は時代遅れと明確に
- でも一応forとかwhile中だったり変数を含む文字列結合はBuilder使いましょうね
- ~~indyで実行時に向き先変えるんで、コンパイル済みのライブラリとかでも恩恵を受ける~~
    - 2017/11/06 modified
    - Java9によってindyで結合するようにコンパイルされたライブラリであれば、以降のバージョンで使用されてもその時々の向き先を使用するようになる
    - tsuyoshi_choさんから頂いた指摘で「indyを使うようにコンパイルされたライブラリ限定」であることを明示して修正

####[Store Interned Strings in CDS Archives](http://openjdk.java.net/jeps/250)
- まず、`java.lang.String#intern()`ってメソッドがあるんですが、そいつが「今までに使用したStringをプールしてて、そこから引っ張ってくる」
- このプールする場所の改良で、「別プロセスでも共有できるプールを用意してメモリを削減する」
- ただし、64bit版かつG1GC利用時の場合のみ適用
- メモリ削減が目標なので高速化とかはしない、というか少し遅くなってる模様、「<2-3%」だから「2-3%以内の劣化にとどまる」かしら
- そもそも`java.lang.String#intern()`が重い処理なので気にする内容ではない気がする

###[Deprecate the Applet API](http://openjdk.java.net/jeps/289)
アプレット？　奴なら死んだよ。

###[Unicode 8.0](http://openjdk.java.net/jeps/267)
何気なくバージョンアップされている内部表現。
[Unicode7.0](http://openjdk.java.net/jeps/227)も居る。

###[Make G1 the Default Garbage Collector](http://openjdk.java.net/jeps/248)
- もう一杯(ry
- デフォルトのガーベッジコレクタがG1になります
- ヒープを分割統治するので大容量ヒープの際にガーベッジコレクトに必要な時間が予測可能かつ小規模に
- 有効なヒープサイズは6GBあたりからであるもよう
- GCチューニング専門の人は「1度あたりのGC時間から逆算してリージョンサイズを決めること」って言ってた

###[UTF-8 Property Files](http://openjdk.java.net/jeps/226)
- 地味にリソースバンドルにUTF-8が使えるようになる
- ISO-8859-1とUTF-8で明示して使い分け可能

###java.util.stream.Streamの処理が増える
- `Predicate`を受け取って、条件を満たすまで続く無限Streamとか地味にうれしい
- パラレルな`Files.lines()`とかもうれしい
    - でもメモリマッピングしてかららしいのでやっぱりシーケンシャルに`Stream#read()`することが多そう
    - そもそもパラレルにjava.ioのStream使ってうれしくなる状況とかほぼなさそう、分散系のファイルシステム、ブロードキャストぐらい？

###[Convenience Factory Methods for Collections](http://openjdk.java.net/jeps/269)
`Set<String> s = Set.of("a", "b", "c");`
作らなくてもよくなる。

###[Java-Level JVM Compiler Interface](http://openjdk.java.net/jeps/243)
- JVMに対してマシンコードをぶち込めるとかいう触れてはいけない案件
- 動的コンパイラを作成する際とかに使用するものらしく、[Graal](http://openjdk.java.net/projects/graal/)で使用するとか
- JITの進み具合とか、現在コードがどういう風に展開されているかを取得するAPIが存在
- さすがに起動時オプションを指定しないと適用されない


##他
- [JavaVM「Eclipse OpenJ9」公開。IBMが「Java 9と同時にオープンソース化する」との約束を果たす](http://www.publickey1.jp/blog/17/javavm_eclipse_openj9.html)
    - JavaEEもIBMに行くのです
    - EE4J(Eclpse Enterprise for Java)っていうらしいよ　→　[Introducing EE4J: Java EE takes first steps into Eclipse Foundation](https://jaxenter.com/ee4j-java-ee-eclipse-foundation-137668.html)