10のJava9で変わるJava8の嫌なとこ！

1. 10のJava9で変わるJava8の嫌なとこ！

2. ● Java9で解決されるJava8で嫌なことランキング
– 個人的主観に基づく
– どのように解決されるかを紹介
– Java9に上げるときに，気をつけることなども紹介
●
細かくは紹介しないので，気になったものがあった
ら調べてください
– 過去のリリースの既知の事も詳しく説明しない

3. Jigsaw(モジュール化)
JShell(JavaのREPL)
G1GCデフォルト化

5. 10位
コンパイルに時間かかりすぎ

6. コンパイルに時間かかりすぎ
class C<T> {
C() {}
C(T t) {}
C(C<T> c) {}
static <U> C<U> m(C<U> c) {return c;}
public static void main(String... args) {
C<String> c = m(new C<>(m(new C<>(m(new C<>())))); // 1秒以下
}
}

7. コンパイルに時間かかりすぎ
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>())))))))))
// ネスト5: Javac(2.02s), ECJ(1.17s)

8. コンパイルに時間かかりすぎ
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>())))))))))))))
// ネスト7: Javac(14.99s) ECJ(10.82s)

9. コンパイルに時間かかりすぎ
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>(
m(new C<>())))))))))))))))))))
//ネスト10

10. コンパイルに時間かかりすぎ
1分？
10分？
20分？
60分/それ以上？

11. 60分以上

12. コンパイルに時間かかりすぎ
● 型検査とオーバロード解決/型推論は同時に行う
– m(new C<>(expr))
● C(T)と仮定して，exprの型検査とオーバロード解決/型推論
● C(C<U>)と仮定して，exprの型検査とオーバロード解決/型推論
– expr=m(new C<>(expr1))なら指数的に増加

13. コンパイルに時間かかりすぎ
● オーバロード数Nとすると
– N*3回，exprの型検査とオーバロード解決/型推論
● Strict, Loose, Varargs for each of overloaded methods

14. Tiered Attribution
● 型検査とオーバーロード解決/型推論を分離
●
型検査
– オーバーロード解決内でやる必要は無かった
● オーバーロード解決/型推論
– 実引数に構造的な型与える
●
推論が必要な場合，型推論情報を持つ
– 何度も同じ式を処理しない(メモ化)

15. 1秒以下

16. 4000倍

17. 9位
Stringの+のコード生成がイケてない

18. String +のコード生成
String s = “aaa” + hoge + foo
↓
StringBuilder s$sb = new StringBuilder();
s$sb.append(“aaa”).append(hoge).append(foo);
String s = s$sb.toString();

19. String +のコード生成
● 将来のJDKでFastestStringBuilderが実装されたら
– 過去のJDKでコンパイルされたコード
● StringBuilderに強く依存
● 将来のJDKで動かしてもFastestStringBuilderが使われない
– 実際にこれは過去にあったこと
● StringBufferからStringBuilderに
– 全てのコードをコンパイルし直す必要
●
コンパイラのメンテナンスコスト大
– コード生成処理って，地獄・・・

20. invokedynamicを使う
public java.lang.String m(java.lang.String, int);
descriptor: (Ljava/lang/String;I)Ljava/lang/String;
flags: ACC_PUBLIC
Code:
stack=2, locals=3, args_size=3
0: aload_1
1: iload_2
2: invokedynamic #5, 0 // InvokeDynamic
#0:makeConcatWithConstants:(Ljava/lang/String;I)Ljava/lang/String;
7: areturn

21. invokedynamicを使う
●
ライブラリが文字列連結
● 将来のJDKでFastestStringBuilderが実装された
ら
– 過去のJDKでコンパイルされたコード
● FastestStringBuilderが使われる
– コンパイルし直す必要なし！

22. 懸念点
● Android N未満だと動かなくなるかも？
– invokedynamic解釈できない
– -XdstringConcat=inline でレガシーバイトコード生成

23. 8位
匿名クラスにダイアモンド演算子
が使えない！

24. 匿名クラス+ダイアモンド演算子
List<String> list = new ArrayList<String>() {{
add(“hoge”);
}};
// JAX-RS client
List<String> res = target.get(new GenericType<String>(){});

25. 使えるようになります
List<String> list = new ArrayList<>() {{
add(“hoge”);
}};
// JAX-RS client
List<String> res = target.get(new GenericType<>(){});

26. 7位
Javadocイケてない！
検索もできない！
HTML4で時代遅れ！

27. 検索できるようになります！

28. 検索できるようになります！

29. モジュールがトップに表示
●
頑張ってどのパッケージがどのモジュールに属すか
覚えましょう

30. ６位ぐらい
Deprecated意味ない，情報少ない

31. @Decprecated
@Deprecated
public void stop() {…}
● どういうDeprecated？？？
– いつDeprecatedになったの？？？
– いつか削除されるの？？？

32. @Deprecatedが変わる！
@Deprecated(
forRemoval = false, // 将来削除される？
since = “1.2”) // いつからDepr.に？
public void stop() {...}

33. Changin Depr. In JDK
● add @Deprecated to constructors for boxed primitives (Boolean, Integer, etc.) (JDK-8145468)
● add @Deprecated(forRemoval=true) to the Runtime.traceInstructions and Runtime.traceMethodCalls
methods (JDK-8153330)
● add @Deprecated to various java.applet and related classes (JEP 289)
● add @Deprecated to java.util.Observable and Observer (JDK-8154801)
● add @Deprecated(forRemoval=true) to various superseded security APIs, including java.security.acl (JDK-
8157847), javax.security.cert and com.sun.net.ssl (JDK-8157712), java.security.Certificate (JDK-8157707),
and javax.security.auth.Policy (JDK-8157848)
● add @Deprecated to "legacy collection" implementations Dictionary, Enumeration, Hashtable, Stack, and
Vector (JDK-8145469)
● add @Deprecated to java.util.Timer and TimerTask (JDK-8154799)
● add @Deprecated to the Optional.get method (JDK-8160606)
● add @Deprecated to java.util.Date, Calendar, and related classes (JDK-8164898)
● add @Deprecated to java.lang.Compiler (JDK-4285505)
● add @Deprecated to the java.corba module
● modify already-deprecated methods Thread.destroy(), Thread.stop(Throwable), Thread.countStackFrames(),
System.runFinalizersOnExit(), and various disused Runtime and SecurityManager methods to have
@Deprecated(forRemoval=true) (JDK-8145468)
● remove @Deprecated from java.awt.Component.show and hide

34. 警告のルールも変わる！
| API declaration site
use site | not dep. forRemoval
context | false true
+----------------------------------
not dep. | 警告 警告
forRemoval=false | 警告
forRemoval=true | 警告

35. @SuprressWarning
● “deprecation”
– forRemoval = falseの警告を抑制
● “removal”
– forRemoval = trueの警告を抑制
●
両方抑えたかったら
– @SuppressWarning({“deprecation”, “removal”})

36. jdeprscan
● jar内のDeprecatedなAPIの使用を検出

37. 5位
Collectionのstaticファクトリー無いの不便

38. 初期値付き不変コレクション生成
● Arrays.asList(“abc”);
● Set<String> s = Collections.unmodifiableSet(
new HashSet<>(Arrays.asList(“abc”)));
● Collections.unmodifiableSet(
new HashMap<Integer, String>() {{
put(0, “hoge”);
}});

39. staticファクトリーできました！
● List#of
– List.of(“abc”)
● Set#of
– Set.of(“abc”)
● Map#of
– Map.of(0, “hoge”)
– Map.ofEntries(Map.entry(0, “hoge”))
● それぞれ0〜10要素までオーバロード
– それ以上は可変長引数
●
全てイミュータブル
– 変更，追加しようとすると例外

40. Guava使ってるなら要らない？

41. 4位
Stream全然便利じゃない！

42. Infinit Stream
Stream.iterate(1, i → i*2+3)...
Stream.generate(() → new Hoge())...
● このまま終端操作を実行すると，無限ループに
– forEach, collect, reduce
– Finite Streamにする必要がある

43. To Finite Stream
● limit(n)
– 先頭からn件の有限Streamに
●
これ以外に手段がない！
– ある条件を満たすまで，とか

44. 条件でskip/limitできるように
● takeWhile(Predicate)
– 条件でlimit
– Stream.iterate(1, i → i*2+3)
.takeWhile(i → i < 100)...
● dropWhile(Predicate)
– 条件を満たす間skip

45. for文的Stream生成
● Stream#iterate(T t, Predicate p, T→T next)
– for (T t; p.test(t); t = next.apply(t)) {…}
– Stream.iterate(2, i → i<100, i → i*2+3)

46. StreamとOptionalの相互運用
● List<Optional<String>> opts = …;
● opts.stream()
.filter(Optional::isPresent)
.map(Optional::get)
.・・・

47. StreamとOptionalの相互運用
● List<Optional<String>> opts = …;
● opts.stream()
.flatMap(Optional::stream)
.・・・

48. その他
● Stream<LocalDate> LocalDate.datesUntil(
LocalDate endExclusive)
● Stream<LocalDate> LocalDate.datesUntil(
LocalDate endExclusive, Period step)
● Stream<String> Scanner.tokens()
● Stream<MatchResult> Scanner.findAll(Pattern pattern)
● Stream<MatchResult> Matcher.results()

49. 3位
Javaのバージョン意味不明

50. いままでのJavaバージョン
● JDK 7 Update 55
–
● JDK 7 Update 60
–

51. いままでのJavaバージョン
● JDK 7 Update 55
– セキュリティーアップデート(CPU)
● JDK 7 Update 60
– マイナーアップデート
●
どちらも同じセキュリティーパッチが入っている

52. バージョンスキームが変わります
● Java $MAJOR.$MINOR.$SECURITY
– Java 9.1.3
● Java9
● マイナーバージョンアップ1回
● セキュリティー3回
● -$PRE+$BUILD-$OPT
– -$PRE: eaとかの情報
– +$BUILD: ビルドナンバー
– -$OPT: 追加のビルド情報，日付など

53. Runtime.Versionクラス
Runtime.Version version = Runtime.version();
int major = version.major();
int minor = version.minor();
int security = version.security();

54. バージョンスキームに依存するコードは
動かなくなるかも！
● System.getProperty("java.version") => "9"
● System.getProperty("java.version").charAt(3)
– 例外に！！

55. 2位
● ちょっとしたAPIの確認面倒くさい！
● もっと気軽にJava書きたい！

56. jshell; Java REPL Tool来る！
jshell> Runtime.version()
$8 ==> 9-ea+122
jshell> $8.major()
$9 ==> 9
jshell> $8.minor()
$10 ==> 0
jshell> $8.pre()
$11 ==> Optional[ea]
jshell>

58. 1位
パッケージ管理イケてない！

59. クラスパス地獄
public is too public

60. モジュール化(Jigsaw)
// module-info.java
module mymodule {
requires java.compiler;
// java.compilerというモジュールを利用
// java.compilerモジュールファイルで
// exportされているパッケージ内のpublicクラスが利用可
exports com.mymodule.util;
// com.mymodule.util内のpublicクラスを他モジュールが利用可に
}

61. モジュール化すると・・・？
●
クラスパスの指定がほぼ要らなくなる
– modulepathを指定する
● ディレクトリ1つだけ
● public classの可視性を管理できる
⇔今まで使用してた内部APIにアクセスできなくなる！？

63. 他にも
● HTTP2.0
● Compact Strings
● VarHandle
● G1GCデフォルト化
– CMSがDeprecatedに
● ｊavacの-releaseオプション
● Applet APIがDeprecatedに

64. More Future(Java 10〜)
● ローカル変数でvalが！
– val hoge = “hoge”;
●
ジェネリクスの特殊化
– List<int> ints;
●
値型
– 構造体みたいなの
– メモリ使用量削減
● Foreign Function Interface