Groovy Shell Scripting 2015
Se está descargando tu SlideShare.
×
Eche un vistazo a continuación
Más Contenido Relacionado
Presentaciones para usted (20)
A los espectadores también les gustó (20)
Similares a Java SE 9の紹介: モジュール・システムを中心に (20)
Más de Taku Miyakawa (16)
Más reciente (20)
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
- 5. 演目 そもそも Java SEってなんだっけ？ Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 5/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
- 10. 演目 そもそも Java SEってなんだっけ？ Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 10/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
- 70. 演目 そもそも Java SEってなんだっけ？ Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 70/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
