Java SE 9の紹介: モジュール・システムを中心に

1. Java SE 9の紹介: モジュール・システムを中心に 2017-11-18 JJUG CCC 2017 Fall ハッシュタグ: #ccc_e4 #jjug_ccc 宮川拓

2.  @miyakawa_taku  JJUG幹事です  株式会社JSOLで働いてます  尾上部屋の里山さんのファンです  オレオレJVM言語Kinkを作っています https://bitbucket.org/kink/kink 自己紹介 #ccc_e4 2/104

3. #ccc_e4本セッションのあらまし  9月にJava SE 9がリリースされました  新しく導入されたモジュール・システムを解説します  その他のアップデートも概観します 3/104

4. 演目そもそも Java SEってなんだっけ？ Java SE 9のモジュール・システム Java SE 9のその他のアップデート #ccc_e4 4/104

6. #ccc_e4Java SEとは Java SE: Java処理系の規格  正式名称: Java Standard Edition  規格の中身:  言語仕様  Java仮想マシンの仕様  標準APIの仕様 6/104

7. #ccc_e4ちなみに: Java EEとは Java EE: APサーバの規格  正式名称: Java Enterprise Edition  規格の中身:  サーブレット  JMX  EJB  ... 7/104

8. Java SEタイムライン #ccc_e4 ジェネリクス, Concurrency Utilities ServiceLoader invokedynamic ラムダ式, Stream API モジュール・システム (a.k.a. Jigsaw) 2004.10 Java SE 5 2006.12 Java SE 6 2011.07 Java SE 7 2014.03 Java SE 8 2017.09 Java SE 9 2018.03 Java SE 18.3 var記法？ 1 0 年戦える言語に Functional Java 基盤の大改造 8/104

9. #ccc_e4Java SE 9はどんなリリース？ Java SE 9:  プログラムの字面のレベルでは地味  アプリケーション基盤には影響大  モジュール・システムの導入！ 9/104

11. #ccc_e4モジュール・システムこのセクションの目的:  モジュール・システム対応に向けて、心の準備ができること 11/104

12. #ccc_e4モジュール・システム内容:  モジュール・システム導入の背景  モジュール・システムの基本  リフレクション  コンパイルと実行  モジュール世界への移行  モジュールのテスト  高度なトピック 12/104

13. モジュール・システム導入の背景 #ccc_e4 13/104

14. #ccc_e4Java 8までの課題  JAR地獄  「内部向けパッケージ」の存在 14/104

15. #ccc_e4～Java 8: JAR地獄  JAR地獄 := 大量のJARがクラスパスに展開されて、混沌にブチ込まれること  「このJARいらないんじゃない？」  → 消したら実行時エラー  Maven, Gradleのような依存性管理ツールを使えば少しはマシだけど…… 15/104

16. #ccc_e4～Java 8: JAR地獄複数バージョン混在地獄ゲーム Ace Shooter matrix-1.0.0.jar matrix-impl-2.0.0.jar matrix-api-2.0.0.jar physics.jar 名前の異なるMavenアーティファクトが同じパッケージ/クラスを含む場合があり得る org.example.matrix.api.* org.example.matrix.impl.* org.example.matrix.api.* org.example.matrix.impl.* 😥 16/104

17. #ccc_e4～Java 8: 内部向けパッケージ  プラットフォームやライブラリ内で、「内部向け」パッケージを作ることがある  org.kink_lang.kink.internal.xxx  sun.misc (JDK内)  内部向けパッケージは本来、ライブラリ外からの使用を想定していない  が、しかし 17/104

18. #ccc_e4～Java 8: 内部向けパッケージ GitHubで“import sun.misc.Unsafe”を検索 18/104

19. ～Java 8: 内部向けパッケージ #ccc_e4 😥 19/104

20. #ccc_e4～Java 8: 内部向けパッケージ  内部使用向けのはずのUnsafeクラスが広く使われてしまっている  性能を絞り出すため……  なにが問題か？  移植性の低いプログラムの蔓延  既存のプログラムを壊さないように配慮すると、実装の改善がしづらい 20/104

21. モジュール・システムの基本 #ccc_e4 21/104

22. #ccc_e4モジュール・システム Java SE 9での解決策  JARを名前付きのモジュールとして、カプセル化された配置の単位に  これまでの課題:  JAR地獄 → モジュール単位で依存関係を整理  内部向けパッケージ → 外部からの使用を実質的に制限 22/104

23. #ccc_e4モジュール・システム各JARファイルが名前付きのモジュールに ace-shooter.jar = module net.example.ace_shooter matrix.jar = module org.example.matrix physics.jar = module jp.example.physics モジュール名は逆ドメイン名方式が推奨 23/104

24. パッケージ衝突の検知 #ccc_e4 module net.example.ace_shooter module org.example.matrix module org.example.matrix.impl module org.example.matrix.api module jp.example.physics 複数のモジュールが同一パッケージを含む場合、起動時に検知される † org.example.matrix.impl.* org.example.matrix.api.* org.example.matrix.api.* org.example.matrix.impl.* 😃 24/104

25. #ccc_e4module-info.java モジュール名はソースディレクトリのトップレベルのmodule-info.javaで宣言 module org.example.matrix { } JARファイルのトップレベルの module-info.class コンパイル 25/104

26. 公開パッケージの指定 #ccc_e4 module org.example.matrix { exports org.example.matrix.api; } モジュールは、他のモジュールに対して公開するパッケージをexports命令で指定する exportされたパッケージはモジュールの外部仕様の一部とみなせる 26/104

27. 使うモジュールの指定 #ccc_e4 module jp.example.physics { requires org.example.matrix; } モジュールは、自分が使うモジュールを、 requires命令で指定するモジュールが使えるクラスの条件:  requiresした先のモジュールの  exportsされたパッケージの  publicなクラス → 該当しないクラスを使うとコンパイルエラー / 実行時例外 27/104

28. exports / requires #ccc_e4 module A { requires B; } module B { exports B.api; requires C; } module C { exports C.api; } B.apiパッケージ B.implパッケージ C.apiパッケージ → 😃使える → 😥使えない → 😥使えない C.apiパッケージ → 😃使える 28/104

29. exports / requires #ccc_e4 module A { requires B; } module B { exports B.api; requires C; } module C { exports C.api; } A.xxxパッケージ → 😃使える自分のモジュール内のパッケージは、非公開でも使える B.xxxパッケージ C.xxxパッケージ → 😃使える → 😃使える 29/104

30. exports / requires #ccc_e4 module A { requires B; } module B { exports B.api; requires C; } requiresしたモジュールが存在しないとコンパイルエラー / 実行時例外 30/104

31. #ccc_e4標準モジュール Java SEの標準ライブラリも、モジュールに分割されている  java.baseモジュールは暗黙的にrequiresされる  それ以外は明示的にrequiresする必要ありモジュールパッケージ群 java.base java.lang, java.util, java.io, ... java.sql java.sql, javax.sql, ... java.desktop java.awt, javax.swing, ... ... ... 31/104

32. リフレクション #ccc_e4 32/104

33. #ccc_e4リフレクションモジュールのカプセル化はリフレクションにも適用される  外部モジュールからアクセスできるのは、 exportsされたパッケージの、公開クラスの、公開メンバだけ  requires関係は不要  非公開なメンバへのアクセスは、外部モジュールからは通常不可能 33/104

34. #ccc_e4リフレクション困る例: DI先のクラス package net.example.ace_shooter.engine; public class GameEngine { @Inject private PerfMonitor perfMonitor; ... } public にしたくない 34/104 exportsしたくないリフレクションで触ってほしいクラスは必ずしも公開したいわけではない

35. #ccc_e4リフレクション必要な緩和策:  パッケージをexportsしたくない  メンバをpublicにしたくない  でもリフレクションでアクセスさせたい 35/104

36. #ccc_e4opens命令 opens命令でパッケージを指定することで、外部からリフレクションができるようになる module net.example.ace_shooter { opens net.example.ace_shooter.core; ... } 36/104

37. #ccc_e4openモジュールモジュール宣言にopenを修飾すると、すべてのパッケージがopens指定される open module net.example.ace_shooter { ... } 37/104

38. リフレクション #ccc_e4 リフレクションはもはや魔法の杖ではない！ 38/104

39. コンパイルと実行 #ccc_e4 39/104

40. #ccc_e4コンパイルと実行注意点:  プログラムのコンパイル方法、実行時のプログラム配置方法はJava SE実装依存  本セッションは、Java SEの参照実装であるOracle JDKを前提とする 40/104

41. #ccc_e4 41/104 モジュールパスモジュールパス:  モジュールのJARファイルを配置するパス  クラスパスとは別！

42. #ccc_e4コンパイル javacコマンドの主なオプションオプション内容 --module-path ¥ {モジュールパス} 依存先モジュールのモジュールパス --module-source-path ¥ {モジュールソースパス} 複数モジュールを同時コンパイルする時、モジュールのソースディレクトリの配置先を指定 ※あまり使わないはず --module-version ¥ {バージョン} モジュールのバージョン ※いまのところ使い道は無い 42/104

43. 実行構成 #ccc_e4実行初期モジュール（mainを含むモジュール）から推移的に参照されるモジュールだけが、実行構成に含まれる（基本的に） module Main java.base java.desktop java.sql module X module Y module Z 43/104 モジュールパス Zやjava.sqlはリフレクションでも触れない

44. #ccc_e4実行 javaコマンドの主なオプションオプション内容 --module-path ¥ {モジュールパス} モジュールパス --module ¥ {初期モジュール名}/{メインクラス } mainメソッドを持つクラス --module {初期モジュール名} 初期モジュール --add-modules ¥ {モジュール名},{モジュール名},... 初期モジュールから推移的に参照されないモジュールを実行構成に追加 44/104

45. 経過措置 #ccc_e4 45/104

46. #ccc_e4経過措置  現時点で、多くのプログラムのJARは、 module-info.classを含んでいない  モジュールの世界への経過措置として、二種類の特殊なモジュールが導入された  無名モジュール  自動モジュール 46/104

47. #ccc_e4無名モジュール  クラスパス上のクラスファイルは、無名モジュールの中でロードされる  無名モジュールは:  モジュール名を持たない  すべてのモジュールをrequiresする  すべてのパッケージをexportsする  Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能 47/104

48. #ccc_e4自動モジュール  モジュールパス上のJARファイルのうち、 module-info.classを持たないものは、自動モジュールとしてロードされる  自動モジュールは:  モジュールパス上のすべてのモジュールをrequiresする  すべての無名モジュールをrequiresする  すべてのパッケージをexportsする  すべてのパッケージをopensする 48/104

49. #ccc_e4自動モジュール自動モジュールのモジュール名の決定方法: 1. JARのMANIFEST.MFファイルが Automatic-Module-Name属性を持っている場合、その値がモジュール名 2. そうでない場合、JARファイル名を元にモジュール名が作られる  commons-io.jar → commons_ioモジュール 49/104

50. モジュール世界への移行 #ccc_e4 50/104

51. #ccc_e4モジュール世界への移行ソフトウェア種別ごとのモジュール化指針：種別モジュール化指針ライブラリいますぐモジュール化！プラグイン基盤ミドルウェア次第 APサーバ上のアプリケーション基盤ミドルウェア次第 ※Java EE 8はモジュール非対応スタンドアロンのアプリケーション遅くなりすぎない程度にモジュール化する場合もしない場合も、 JDK9への移行ガイドは必読 51/104

52. #ccc_e4ライブラリのモジュール化ライブラリのモジュール化が喫緊な理由:  ライブラリを使う側のプログラムが、 requires命令を書けるようにするため 52/104

53. #ccc_e4ライブラリのモジュール化 JARファイル名ベースの自動モジュールを requiresしてはいけない！ module org.example.matrix { requires commons_io; ... } 😥 駄目パターン: → Commons IOに本当のモジュール名が付いたとき、ライブラリを使う側のプログラムが不整合になる ※ requires staticは許容範囲 53/104

54. #ccc_e4ライブラリのモジュール化モジュール化のフローすべての requires先JAR のモジュール名が決まるまで待つ Automatic-Module-Nameでモジュール名を決めて公開 module-info.javaを書いて公開すべての requires先JAR のモジュール名が決まっている？ NoYes 54/104

55. #ccc_e4ライブラリのモジュール化 Java SE 8以前をサポートしたい時:  Automatic-Module-Name属性を付ける → これは簡単  module-info.javaが書きたい場合、 module-info.javaだけをJava SE 9用にコンパイルする 55/104

56. モジュールのテスト #ccc_e4 56/104

57. #ccc_e4モジュールのテスト二種類のテストブラックボックス・テスト  モジュールの外からテスト。  exportsされたパッケージの、public なクラスを操作して、仕様どおりに動くことを確かめる。  テストコードは、テスト対象と別モジュール。ホワイトボックス・テスト  モジュールの内側をテスト。  公開・非公開にかかわらず、クラス・メソッドを操作して、意図した実装になっていることを確かめる。  テストコードは、テスト対象と同一モジュール……どうやって？ 57/104

58. #ccc_e4ホワイトボックス・テストホワイトボックス・テストの課題:  テストコードは、JUnit, TestNG, JMockit など、テスト用ライブラリを使う  テスト対象コードは、これらのライブラリをrequiresしていない  コンパイル済みのモジュールに、テストコードのクラスを追加する必要がある 58/104

59. #ccc_e4ホワイトボックス・テストふたつのやり方: 59/104 正攻法 → こちらを解説  テスト対象のモジュール定義を、テストできる構成に一時的に上書き  javac/javaコマンドにオプションを指定次善の策  あきらめてクラスパス上でテスト

60. #ccc_e4モジュール定義の上書き JDKのjavac /javaコマンド共通オプションオプション内容 --add-reads ¥ {モジュール名}={参照先モジュール},... requires定義を追加 --patch-module ¥ {モジュール名}={ファイル,...},... モジュールにソースファイル/クラスファイルを追加 60/104

61. モジュール定義の上書き #ccc_e4 javac ... ¥ --add-reads app=junit ¥ --patch-module app=ATest.java,BTest.java java ... ¥ --add-reads app=junit ¥ --patch-module app=ATest.class,BTest.class ¥ --add-modules ALL-MODULE-PATH コンパイル実行モジュールパス上の全JARを実行構成に含める 61/104

62. 高度なトピック #ccc_e4 62/104

63. #ccc_e4SPI SPIの仕組みはモジュール・システムに統合された  サービスを使うモジュールは、 uses命令でSPIを指定  サービスを提供するモジュールは、 provides命令でサービスの実装を指定 63/104

64. #ccc_e4requires static コンパイル時に必要だが、実行時には不要なモジュールを、requires static命令で指定できる  例: JSR 305の@Nullableアノテーション 64/104

65. ブートレイヤー #ccc_e4モジュールレイヤーモジュールレイヤー: モジュールの名前空間 java.base java.sql jp.example.app_container java.desktop java.logging アプリ X のレイヤーアプリ Yのレイヤー com.example.app_x org.example.app_y net.example.utils net.example.utils 子親子親アプリケーションコンテナや、プラグイン機構の基礎となる仕組み 65/104

66. #ccc_e4モジュールレイヤークラスローダーとモジュールレイヤーの関連 Module ModuleLayer ClassLoader Class Package Unnamed Module Named Module 続きはウェブで！ http://d.hatena.ne.jp/miyakawa_taku/20171108/1510145001 66/104

67. #ccc_e4OSGiとの違い  OSGiはコンテナの仕組みを仕様に含むが、 Javaのモジュール・システムはコンテナの仕組みを含まない  Javaのモジュール・システムは、OSGiのようなものを作るための基礎と考えられる 67/104

68. モジュール・システムの参考資料 #ccc_e4 68/104

69. #ccc_e4モジュール・システムの参考資料 Bakker, Mak (2017)『Java 9 Modularity』 69/104

71. #ccc_e4その他のアップデートモジュール・システム以外の主要なアップデートを、対応するJEPを参照しながら見ていく 71/104

72. #ccc_e4JEP  JEP: Java SEの参照実装であるJDKの開発フロー  JEP 261: Module System  JEP 213: Milling Project Coin  ...  JEP自体は規格の一部ではないが、 Java SEを理解するのに役立つ  ※ Javaの規格はJSRで決まる 72/104

73. JEP 269 コレクションのファクトリ #ccc_e4 73/104

74. #ccc_e4コレクションのファクトリ List.of, Set.of, Map.ofメソッドで、不変なコンテナが作れるようになった☆ 74/104

75. List.of #ccc_e4 List<String> a = Collections.emptyList(); List<String> b = Collections.singletonList("foo"); List<String> c = Collections.unmodifiableList(Arrays.asList("foo", "bar")); List<String> a = List.of(); List<String> b = List.of("foo"); List<String> c = List.of("foo", "bar"); ～Java SE 8 Java SE 9 75/104

76. Map.of #ccc_e4 Map<String, Integer> m = new HashMap<>(); m.put("双葉山", 69); m.put("大鵬", 45); m.put("白鵬", 63); Map<String, Integer> yokozuna = Collections.unmodifiableMap(m); ～Java SE 8 Map<String, Integer> yokozuna = Map.of("双葉山", 69, "大鵬", 45, "白鵬", 63); Java SE 9 76/104

77. JEP 213 try-with-resourcesの改善 #ccc_e4 77/104

78. try-with-resourcesの改善 #ccc_e4 try (BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream("foo.txt"), StandardCharsets.UTF_8))) { ... } ～Java SE 8 Java SE 9 BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream("foo.txt"), StandardCharsets.UTF_8)); try (br) { ... } 78/104

79. JEP 213 インタフェースのprivateメソッド #ccc_e4 79/104

80. #ccc_e4インタフェースのprivateメソッドインタフェースにprivateメソッドが定義できるようになった defaultメソッドの実装が複雑になったとき、その一部がprivateメソッドに抽出できる☆ 80/104

81. JEP 213 匿名クラスでダイヤモンド演算子 #ccc_e4 81/104

82. #ccc_e4匿名クラスでダイヤモンド演算子匿名クラスの宣言でダイヤモンド演算子が使えるようになった Java SE 9 Iterator<Integer> inc = new Iterator<>() { private int n = 0; @Override public boolean hasNext() { return true; } @Override public Integer next() { return this.n ++; } }; 82/104

83. JEP 213 「_」1文字識別子の禁止 #ccc_e4 83/104

84. #ccc_e4「_」1文字識別子の禁止「_」1文字の識別子が使えなくなった  ×変数名  ×フィールド名  ×メソッド名  ×クラス名  ×ラムダ式のパラメータ（これは8から） 84/104

85. JEP 226 ResourceBundleプロパティがデフォルトUTF-8に☆ #ccc_e4 85/104

86. ResourceBundle→UTF-8 #ccc_e4 ～Java SE 8 Java SE 9  ResourceBundleのプロパティファイルはデフォルトでLatin-1  日本語などのメッセージはnative2asciiでエスケープする必要があった  ResourceBundleのプロパティファイルがデフォルトでUTF-8に☆  注意: Propertiesクラスのデフォルトは Latin-1のまま 86/104

87. JEP 266 Reactive Streamsサポート #ccc_e4 87/104

88. #ccc_e4Reactive Streamsサポート分散システムのプログラミングモデルである Reactive Streamsをサポート下記のインターフェースを提供  Flow.Publisher  Flow.Subscriber  Flow.Subscription  Flow.Processor 88/104

89. JEP 266 CompletableFutureの強化 #ccc_e4 89/104

90. #ccc_e4CompletableFutureの強化  CompletableFutureクラス:  非同期に完了/キャンセルできるタスク  Promiseパターンを実現する仕組み  Java SE 9で便利メソッドがもろもろ追加  orTimeout: タイムアウト時間を指定  Executorのファクトリ群  などなど 90/104

91. JEP 102 プロセスAPIの強化 #ccc_e4 91/104

92. #ccc_e4プロセスAPIの強化  ProcessHandleクラス:  ネイティブプロセスを表す  PIDや実行ユーザなどが取れる  Process.onExit()メソッド:  プロセス終了時に完了する CompletableFutureを戻す  複数の子プロセスからどれか1つの終了を待ち受ける、のような操作が可能に 92/104

93. 自分自身のPIDを出力 #ccc_e4 Java SE 9 ProcessHandle ph = ProcessHandle.current(); long pid = ph.pid(); System.out.println(pid); // → 12345 93/104

94. JEP 277 @Deprecatedの強化 #ccc_e4 94/104

95. #ccc_e4@Deprecatedの強化 @Deprecatedアノテーションへの属性追加  since: いつから非推奨になったか  forRemoval: 将来削除される予定か Java SE 9 @Deprecated( since = "3.0.0", // 3.0.0から非推奨 forRemoval = ture // 未来のバージョンでは削除予定 ) public class FatOldSun { ... } 95/104

96. JEP 280 文字列結合のindy化 #ccc_e4 96/104

97. #ccc_e4文字列結合のindy化文字列結合演算の実装を処理系が選択できるように、invokedynamic命令のためのブートストラップメソッドが定義された注意！  プログラマにとっての指針は変わらない → 結合を繰り返す時はStringBuilderを使う  この変更で得られるのは、極めて微視的で、処理系依存な高速化の可能性にすぎない  推測するな、（マクロに）計測せよ 97/104

98. JEP 219, 244, 249, 273, 229 セキュリティの改善 #ccc_e4 98/104

99. #ccc_e4セキュリティの改善  JEP 219: DTLS  JEP 244: ALPN  JEP 249: OCSP Stapling for TLS  JEP 273:  SecureRandomのアルゴリズム追加  パラメータ設定用API追加  JEP 229:  PKCS2をキーストアファイルのデフォルトに 99/104

100. JEP 238 マルチリリースJARファイル #ccc_e4 100/104

101. #ccc_e4マルチリリースJARファイル  特定のJava SEバージョン用に、クラスファイル/リソースファイルを上書き  上書き用のファイルの配置場所:  META-INF/versions /<バージョン>/  Java SE 8以前と9を両方サポートするための、最後の手段として使える 101/104

102. 演目 Java SE 9のその他のアップデート Java SE 9のモジュール・システムそもそも Java SEってなんだっけ？ #ccc_e4 102/104

103. 註釈 #ccc_e4 103/104

104. #ccc_e4† パッケージの衝突検知「複数のモジュールが同一パッケージを含む場合、起動時に検知される」  厳密には、「モジュールレイヤーが、モジュール間のパッケージ重複を許さない構成である時、そのモジュールレイヤー内の複数のモジュールが～」である  異なるモジュールレイヤー間では、同じ名前のパッケージが共存できる  defineModulesWithManyLoadersで作られたモジュールレイヤーは、exportされないパッケージの重複を許す 104/104

Java SE 9の紹介: モジュール・システムを中心に

You are reading a preview.

Check these out next

Java SE 9の紹介: モジュール・システムを中心に

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to Java SE 9の紹介: モジュール・システムを中心に (20)

More from Taku Miyakawa (16)

Featured (20)

Recently uploaded (20)