Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

138.266 visualizaciones

Publicado el

Java SE 9を、新たに導入されたモジュール・システム(Jigsaw)を中心として紹介します。JJUG CCC 2017 Fallの発表資料です。

補足:
p. 7 正しくは「JMX」→「JMS (Java Message Service)」。JMXはJava SE内の、モニタリング用の仕組みです。
p. 43 これに加えて、SPIの実装を提供するモジュールも、モジュールレイヤーに含まれます。具体的にはConfiguration.resolveAndBindの動きです。
p. 47「Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能」は、OpenJDKでも同じ動作です。「HotSpot系の」とすべきところでした。

このスライドはCC Attribution Licenseの元に、利用・改変・再配布をライセンスします。

Publicado en: Tecnología
  • Sé el primero en comentar

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

  1. 1. Java SE 9の紹介: モジュール・システムを中心に 2017-11-18 JJUG CCC 2017 Fall ハッシュタグ: #ccc_e4 #jjug_ccc 宮川 拓
  2. 2.  @miyakawa_taku  JJUG幹事です  株式会社JSOLで働いてます  尾上部屋の里山さんのファンです  オレオレJVM言語Kinkを作っています https://bitbucket.org/kink/kink 自己紹介 #ccc_e4 2/104
  3. 3. #ccc_e4本セッションのあらまし  9月にJava SE 9がリリースされました  新しく導入されたモジュール・システムを 解説します  その他のアップデートも概観します 3/104
  4. 4. 演目 そもそも Java SEってなんだっけ? Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 4/104
  5. 5. 演目 そもそも Java SEってなんだっけ? Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 5/104
  6. 6. #ccc_e4Java SEとは Java SE: Java処理系の規格  正式名称: Java Standard Edition  規格の中身:  言語仕様  Java仮想マシンの仕様  標準APIの仕様 6/104
  7. 7. #ccc_e4ちなみに: Java EEとは Java EE: APサーバの規格  正式名称: Java Enterprise Edition  規格の中身:  サーブレット  JMX  EJB  ... 7/104
  8. 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. 9. #ccc_e4Java SE 9はどんなリリース? Java SE 9:  プログラムの字面のレベルでは地味  アプリケーション基盤には影響大  モジュール・システムの導入! 9/104
  10. 10. 演目 そもそも Java SEってなんだっけ? Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 10/104
  11. 11. #ccc_e4モジュール・システム このセクションの目的:  モジュール・システム対応に向けて、 心の準備ができること 11/104
  12. 12. #ccc_e4モジュール・システム 内容:  モジュール・システム導入の背景  モジュール・システムの基本  リフレクション  コンパイルと実行  モジュール世界への移行  モジュールのテスト  高度なトピック 12/104
  13. 13. モジュール・システム 導入の背景 #ccc_e4 13/104
  14. 14. #ccc_e4Java 8までの課題  JAR地獄  「内部向けパッケージ」の存在 14/104
  15. 15. #ccc_e4~Java 8: JAR地獄  JAR地獄 := 大量のJARがクラスパスに 展開されて、混沌にブチ込まれること  「このJARいらないんじゃない?」  → 消したら実行時エラー  Maven, Gradleのような依存性管理 ツールを使えば少しはマシだけど…… 15/104
  16. 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. 17. #ccc_e4~Java 8: 内部向けパッケージ  プラットフォームやライブラリ内で、 「内部向け」パッケージを作ることがある  org.kink_lang.kink.internal.xxx  sun.misc (JDK内)  内部向けパッケージは本来、ライブラリ外 からの使用を想定していない  が、しかし 17/104
  18. 18. #ccc_e4~Java 8: 内部向けパッケージ GitHubで“import sun.misc.Unsafe”を検索 18/104
  19. 19. ~Java 8: 内部向けパッケージ #ccc_e4 😥 19/104
  20. 20. #ccc_e4~Java 8: 内部向けパッケージ  内部使用向けのはずのUnsafeクラスが広く 使われてしまっている  性能を絞り出すため……  なにが問題か?  移植性の低いプログラムの蔓延  既存のプログラムを壊さないように配慮 すると、実装の改善がしづらい 20/104
  21. 21. モジュール・システムの基本 #ccc_e4 21/104
  22. 22. #ccc_e4モジュール・システム Java SE 9での解決策  JARを名前付きのモジュールとして、 カプセル化された配置の単位に  これまでの課題:  JAR地獄 → モジュール単位で依存関係を整理  内部向けパッケージ → 外部からの使用を実質的に制限 22/104
  23. 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. 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. 25. #ccc_e4module-info.java モジュール名はソースディレクトリのトップ レベルのmodule-info.javaで宣言 module org.example.matrix { } JARファイルのトップレベルの module-info.class コンパイル 25/104
  26. 26. 公開パッケージの指定 #ccc_e4 module org.example.matrix { exports org.example.matrix.api; } モジュールは、他のモジュールに対して公開 するパッケージをexports命令で指定する exportされたパッケージは モジュールの外部仕様 の一部とみなせる 26/104
  27. 27. 使うモジュールの指定 #ccc_e4 module jp.example.physics { requires org.example.matrix; } モジュールは、自分が使うモジュールを、 requires命令で指定する モジュールが使えるクラスの条件:  requiresした先のモジュールの  exportsされたパッケージの  publicなクラス → 該当しないクラスを使うと コンパイルエラー / 実行時例外 27/104
  28. 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. 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. 30. exports / requires #ccc_e4 module A { requires B; } module B { exports B.api; requires C; } requiresしたモジュールが存在しないと コンパイルエラー / 実行時例外 30/104
  31. 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. 32. リフレクション #ccc_e4 32/104
  33. 33. #ccc_e4リフレクション モジュールのカプセル化はリフレクションに も適用される  外部モジュールからアクセスできるのは、 exportsされたパッケージの、公開クラ スの、公開メンバだけ  requires関係は不要  非公開なメンバへのアクセスは、 外部モジュールからは通常不可能 33/104
  34. 34. #ccc_e4リフレクション 困る例: DI先のクラス package net.example.ace_shooter.engine; public class GameEngine { @Inject private PerfMonitor perfMonitor; ... } public にしたくない 34/104 exportsしたくない リフレクションで触ってほしいクラスは 必ずしも公開したいわけではない
  35. 35. #ccc_e4リフレクション 必要な緩和策:  パッケージをexportsしたくない  メンバをpublicにしたくない  でもリフレクションでアクセスさせたい 35/104
  36. 36. #ccc_e4opens命令 opens命令でパッケージを指定することで、 外部からリフレクションができるようになる module net.example.ace_shooter { opens net.example.ace_shooter.core; ... } 36/104
  37. 37. #ccc_e4openモジュール モジュール宣言にopenを修飾すると、 すべてのパッケージがopens指定される open module net.example.ace_shooter { ... } 37/104
  38. 38. リフレクション #ccc_e4 リフレクションは もはや魔法の杖ではない! 38/104
  39. 39. コンパイルと実行 #ccc_e4 39/104
  40. 40. #ccc_e4コンパイルと実行 注意点:  プログラムのコンパイル方法、実行時の プログラム配置方法はJava SE実装依存  本セッションは、Java SEの参照実装で あるOracle JDKを前提とする 40/104
  41. 41. #ccc_e4 41/104 モジュールパス モジュールパス:  モジュールのJARファイルを配置する パス  クラスパスとは別!
  42. 42. #ccc_e4コンパイル javacコマンドの主なオプション オプション 内容 --module-path ¥ {モ ジ ュ ー ル パス} 依存先モジュールのモジュールパ ス --module-source-path ¥ {モ ジ ュ ー ル ソ ー ス パス} 複数モジュールを同時コンパイル する時、モジュールのソースディ レクトリの配置先を指定 ※あまり使わないはず --module-version ¥ {バ ー ジ ョン} モジュールのバージョン ※いまのところ使い道は無い 42/104
  43. 43. 実行構成 #ccc_e4実行 初期モジュール(mainを含むモジュール)か ら推移的に参照されるモジュールだけが、 実行構成に含まれる(基本的に) module Main java.base java.desktop java.sql module X module Y module Z 43/104 モ ジ ュ ー ル パ ス Zやjava.sqlはリフレクションでも触れない
  44. 44. #ccc_e4実行 javaコマンドの主なオプション オプション 内容 --module-path ¥ {モ ジ ュ ー ル パス} モ ジ ュ ー ル パ ス --module ¥ {初 期 モ ジ ュ ー ル名}/{メインクラス } mainメソッドを持つ ク ラ ス --module {初期モジュール 名} 初 期 モ ジ ュ ー ル --add-modules ¥ {モ ジ ュ ー ル名},{モジュール 名},... 初 期 モ ジ ュ ー ル か ら 推 移 的 に 参 照 さ れ な い モ ジ ュ ー ル を 実 行 構 成 に 追 加 44/104
  45. 45. 経過措置 #ccc_e4 45/104
  46. 46. #ccc_e4経過措置  現時点で、多くのプログラムのJARは、 module-info.classを含んでいない  モジュールの世界への経過措置として、 二種類の特殊なモジュールが導入された  無名モジュール  自動モジュール 46/104
  47. 47. #ccc_e4無名モジュール  クラスパス上のクラスファイルは、 無名モジュールの中でロードされる  無名モジュールは:  モジュール名を持たない  すべてのモジュールをrequiresする  すべてのパッケージをexportsする  Oracle JDKでは、外部モジュールの非公 開メンバへのリフレクションが可能 47/104
  48. 48. #ccc_e4自動モジュール  モジュールパス上のJARファイルのうち、 module-info.classを持たないものは、 自動モジュールとしてロードされる  自動モジュールは:  モジュールパス上の すべてのモジュールをrequiresする  すべての無名モジュールをrequiresする  すべてのパッケージをexportsする  すべてのパッケージをopensする 48/104
  49. 49. #ccc_e4自動モジュール 自動モジュールのモジュール名の決定方法: 1. JARのMANIFEST.MFファイルが Automatic-Module-Name属性を持って いる場合、その値がモジュール名 2. そうでない場合、JARファイル名を元に モジュール名が作られる  commons-io.jar → commons_ioモジュール 49/104
  50. 50. モジュール世界への移行 #ccc_e4 50/104
  51. 51. #ccc_e4モジュール世界への移行 ソフトウェア種別ごとのモジュール化指針: 種別 モジュール化指針 ライブラリ いますぐモジュール化! プラグイン 基盤ミドルウェア次第 APサーバ上の アプリケーション 基盤ミドルウェア次第 ※Java EE 8はモジュール非対応 スタンドアロンの アプリケーション 遅くなりすぎない程度に モジュール化する場合もしない場合も、 JDK9への移行ガイドは必読 51/104
  52. 52. #ccc_e4ライブラリのモジュール化 ライブラリのモジュール化が喫緊な理由:  ライブラリを使う側のプログラムが、 requires命令を書けるようにするため 52/104
  53. 53. #ccc_e4ライブラリのモジュール化 JARファイル名ベースの自動モジュールを requiresしてはいけない! module org.example.matrix { requires commons_io; ... } 😥 駄目パターン: → Commons IOに本当のモジュール名が 付いたとき、ライブラリを使う側のプログラムが 不整合になる ※ requires staticは許容範囲 53/104
  54. 54. #ccc_e4ライブラリのモジュール化 モジュール化のフロー すべての requires先JAR の モジュール名が決まるまで待つ Automatic-Module-Nameで モジュール名を決めて公開 module-info.javaを書いて公開 すべての requires先JAR の モジュール名が決まっている? NoYes 54/104
  55. 55. #ccc_e4ライブラリのモジュール化 Java SE 8以前をサポートしたい時:  Automatic-Module-Name属性を付ける → これは簡単  module-info.javaが書きたい場合、 module-info.javaだけをJava SE 9用に コンパイルする 55/104
  56. 56. モジュールのテスト #ccc_e4 56/104
  57. 57. #ccc_e4モジュールのテスト 二種類のテスト ブ ラ ッ ク ボ ッ ク ス ・テスト  モ ジ ュ ー ル の 外 か ら テ スト 。  exportsされたパッケージの、public な ク ラ ス を 操 作 し て 、 仕 様ど お りに 動 く ことを確かめる。  テ ス ト コ ー ド は 、 テ ス ト対 象 と 別 モ ジ ュ ー ル 。 ホ ワ イ ト ボ ッ ク ス ・テスト  モ ジ ュ ー ル の 内 側 を テ スト 。  公 開 ・ 非 公 開 に か か わ らず 、 クラ ス ・ メ ソ ッ ド を 操 作 し て 、 意図 し た実 装 に なっていることを確かめる。  テ ス ト コ ー ド は 、 テ ス ト対 象 と 同 一 モ ジ ュ ー ル……どうやって? 57/104
  58. 58. #ccc_e4ホワイトボックス・テスト ホワイトボックス・テストの課題:  テストコードは、JUnit, TestNG, JMockit など、テスト用ライブラリを使う  テスト対象コードは、これらのライブ ラリをrequiresしていない  コンパイル済みのモジュールに、テスト コードのクラスを追加する必要がある 58/104
  59. 59. #ccc_e4ホワイトボックス・テスト ふたつのやり方: 59/104 正攻法 → こちらを解説  テスト対象のモジュール定義を、 テストできる構成に一時的に上書き  javac/javaコマンドにオプションを指定 次善の策  あきらめてクラスパス上でテスト
  60. 60. #ccc_e4モジュール定義の上書き JDKのjavac /javaコマンド共通オプション オプション 内容 --add-reads ¥ {モ ジ ュ ー ル名}={参照先モジュール},... requires定義を追加 --patch-module ¥ {モ ジ ュ ー ル名}={ファイル,...},... モ ジ ュ ー ル に ソ ー ス フ ァ イ ル/クラス フ ァ イ ル を 追 加 60/104
  61. 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. 62. 高度なトピック #ccc_e4 62/104
  63. 63. #ccc_e4SPI SPIの仕組みはモジュール・システムに統合 された  サービスを使うモジュールは、 uses命令でSPIを指定  サービスを提供するモジュールは、 provides命令でサービスの実装を指定 63/104
  64. 64. #ccc_e4requires static コンパイル時に必要だが、実行時には不要な モジュールを、requires static命令で指定で きる  例: JSR 305の@Nullableアノテーション 64/104
  65. 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. 66. #ccc_e4モジュールレイヤー クラスローダーとモジュールレイヤーの関連 Module ModuleLayer ClassLoader Class Package Unnamed Module Named Module 続きはウェブで! http://d.hatena.ne.jp/miyakawa_taku/20171108/1510145001 66/104
  67. 67. #ccc_e4OSGiとの違い  OSGiはコンテナの仕組みを仕様に含むが、 Javaのモジュール・システムはコンテナの 仕組みを含まない  Javaのモジュール・システムは、OSGiの ようなものを作るための基礎と考えられる 67/104
  68. 68. モジュール・システムの 参考資料 #ccc_e4 68/104
  69. 69. #ccc_e4モジュール・システムの参考資料 Bakker, Mak (2017)『Java 9 Modularity』 69/104
  70. 70. 演目 そもそも Java SEってなんだっけ? Java SE 9の モジュール・システム Java SE 9の その他のアップデート #ccc_e4 70/104
  71. 71. #ccc_e4その他のアップデート モジュール・システム以外の主要なアップ デートを、対応するJEPを参照しながら 見ていく 71/104
  72. 72. #ccc_e4JEP  JEP: Java SEの参照実装であるJDKの開発 フロー  JEP 261: Module System  JEP 213: Milling Project Coin  ...  JEP自体は規格の一部ではないが、 Java SEを理解するのに役立つ  ※ Javaの規格はJSRで決まる 72/104
  73. 73. JEP 269 コレクションのファクトリ #ccc_e4 73/104
  74. 74. #ccc_e4コレクションのファクトリ List.of, Set.of, Map.ofメソッドで、不変な コンテナが作れるようになった☆ 74/104
  75. 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. 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. 77. JEP 213 try-with-resourcesの改善 #ccc_e4 77/104
  78. 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. 79. JEP 213 インタフェースのprivateメソッド #ccc_e4 79/104
  80. 80. #ccc_e4インタフェースのprivateメソッド インタフェースにprivateメソッドが定義でき るようになった defaultメソッドの実装が複雑になったとき、 その一部がprivateメソッドに抽出できる☆ 80/104
  81. 81. JEP 213 匿名クラスでダイヤモンド演算子 #ccc_e4 81/104
  82. 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. 83. JEP 213 「_」1文字識別子の禁止 #ccc_e4 83/104
  84. 84. #ccc_e4「_」1文字識別子の禁止 「_」1文字の識別子が使えなくなった  ×変数名  ×フィールド名  ×メソッド名  ×クラス名  ×ラムダ式のパラメータ (これは8から) 84/104
  85. 85. JEP 226 ResourceBundleプロパティが デフォルトUTF-8に☆ #ccc_e4 85/104
  86. 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. 87. JEP 266 Reactive Streamsサポート #ccc_e4 87/104
  88. 88. #ccc_e4Reactive Streamsサポート 分散システムのプログラミングモデルである Reactive Streamsをサポート 下記のインターフェースを提供  Flow.Publisher  Flow.Subscriber  Flow.Subscription  Flow.Processor 88/104
  89. 89. JEP 266 CompletableFutureの強化 #ccc_e4 89/104
  90. 90. #ccc_e4CompletableFutureの強化  CompletableFutureクラス:  非同期に完了/キャンセルできるタスク  Promiseパターンを実現する仕組み  Java SE 9で便利メソッドがもろもろ追加  orTimeout: タイムアウト時間を指定  Executorのファクトリ群  などなど 90/104
  91. 91. JEP 102 プロセスAPIの強化 #ccc_e4 91/104
  92. 92. #ccc_e4プロセスAPIの強化  ProcessHandleクラス:  ネイティブプロセスを表す  PIDや実行ユーザなどが取れる  Process.onExit()メソッド:  プロセス終了時に完了する CompletableFutureを戻す  複数の子プロセスからどれか1つの終了 を待ち受ける、のような操作が可能に 92/104
  93. 93. 自分自身のPIDを出力 #ccc_e4 Java SE 9 ProcessHandle ph = ProcessHandle.current(); long pid = ph.pid(); System.out.println(pid); // → 12345 93/104
  94. 94. JEP 277 @Deprecatedの強化 #ccc_e4 94/104
  95. 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. 96. JEP 280 文字列結合のindy化 #ccc_e4 96/104
  97. 97. #ccc_e4文字列結合のindy化 文字列結合演算の実装を処理系が選択できる ように、invokedynamic命令のためのブート ストラップメソッドが定義された 注意!  プログラマにとっての指針は変わらない → 結合を繰り返す時はStringBuilderを使う  この変更で得られるのは、極めて微視的で、 処理系依存な高速化の可能性にすぎない  推測するな、(マクロに)計測せよ 97/104
  98. 98. JEP 219, 244, 249, 273, 229 セキュリティの改善 #ccc_e4 98/104
  99. 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. 100. JEP 238 マルチリリースJARファイル #ccc_e4 100/104
  101. 101. #ccc_e4マルチリリースJARファイル  特定のJava SEバージョン用に、クラス ファイル/リソースファイルを上書き  上書き用のファイルの配置場所:  META-INF/versions /<バージョン>/  Java SE 8以前と9を両方サポートするため の、最後の手段として使える 101/104
  102. 102. 演目 Java SE 9の その他のアップデート Java SE 9の モジュール・システム そもそも Java SEってなんだっけ? #ccc_e4 102/104
  103. 103. 註釈 #ccc_e4 103/104
  104. 104. #ccc_e4† パッケージの衝突検知 「複数のモジュールが同一パッケージを含む場 合、起動時に検知される」  厳密には、「モジュールレイヤーが、モ ジュール間のパッケージ重複を許さない構 成である時、そのモジュールレイヤー内の 複数のモジュールが~」である  異なるモジュールレイヤー間では、同じ名 前のパッケージが共存できる  defineModulesWithManyLoadersで作られた モジュールレイヤーは、exportされない パッケージの重複を許す 104/104

×