[戻る]

Java読書会BOF 「The Java Module System」を読む会 第11回

開催概要
日時 2020年9月12日 10:00 - 17:00
場所 川崎市教育文化会館 第３会議室
出席者(敬称略) 高橋(智)、高橋(徹)、平山、岩室(書記)

15 Putting the pieces together

15.3 The technology landscape

15.3.1 Maven, Gradle, and other bulild tools

  • Gradle, Maven はわりとつい最近モジュール対応した。(Gradle は2020年、Maven は2019年)
  • Gradle in Action (2014) は古過ぎるのではないか?
  • Hadoop で他ライブラリのクラスが直接含まれていて詰みそうになったことがある。module があれば回避できたかも?

15.3.2 OSGi

  • バンドル≒モジュール

  • バンドル≒jarファイル?

  • OSGi in Depth (2011) も古いのではないか?
    • Gradle はかなりアクティブに仕様が変更されているが、OSGi の方は基本的な部分はそう変わらないと思われる。

  • クラスローダが違うので、他の app のクラスは見れない。

  • juxtapose: 比較する、AとBを並べる、対比する

  • Table 15.1: 制限できればチェック、制限できなければ×。

  • OSGi と JPMS はレイヤーが異なる。

  • OSGi はモジュールシステム上で動くか? → 動く

  • OSGi は動的、JPMS は静的。

  • OSGi をどう使うのかの事例が知りたい。「hallo world」的な ⇒ 宿題
    • バンドル間でのオブジェクト操作はどうするか?

  • p.360 「In the end,」から一節の意味がわからない。

  • OSGi を JPMS のモジュールに置き換えられるか?
    • OSGi では同一ライブラリの別バージョンが使えるが、JPMS はどうではないので無理ではないか。

15.3.3 Microservices

  • マイクロサービスに関する議論:

    • 分散トランザクションが必要になる?

    • 2層システムと3層システムの違い?

    • メッセージング

    • どのような場合にマイクロサービス化する意義がある?

    • APIがあればマイクロサービス?

    • マイクロサービス化したシステムでの事例
      • 依存関係があるさまざまなプロセスを立ち上げる必要があるので、利用可能になるのが遅い。
      • 「全てのサービスを起動⇒全てのサービスを終了」という使用方法ではマイクロサービスの意味がないのではないか?

    • マイクロサービスは本当に「マイクロ」か?

    • プロセスを分けられれば jar hell は軽減されるのでは。

    • 関数/メソッド呼び出しをサービス化した場合、サーバプログラミングの世界になる。
      • 例外処理
      • 生死管理
    • サービスの場合、ヒープ管理も重要になるが、JVMの ようにヒープ管理できるものはほぼない。
      • nodejs はできるかもしれない?
        • nodejs ならば JavaScript が使える。
    • マイクロサービスは難しい。
      • APIの設計(≒インプット/アウトプット)ができない。
  • モノリスの中身を適切に分割していれば、マイクロサービスにするのはに簡単?
    • モジュールシステムでモノリスを作っていれば、マイクロサービスに移行するのも簡単?
      • マイクロサービス化は、サーバを作ることになるから簡単にはいかないのではないか?

15.4 Thoughts on a modular ecosystem

Summary

appendix A: Class-path recap

A.1 Using the class path to load application JARs

A.2 The class path since Java 9

appendix B: High-level introduction to the reflection API

B.1 Fundamental types and methods

B.2 Breaking into APIs with setAccessible

  • p.369 下から2行目(ソースコード): field ⇒ protocolField

B.3 Annotations mark code for reflection

appendix C: Observing the JVM with unified logging

C.1 What is unified logging?

C.2 Defining which messages should be shown

  • タグ指定と出力の組み合わせ
    • gc: gcのみの行が出力される (他のタグが含まれていると出力されない)
    • gc+heap: gcとheapの両方がある行のみが出力される (他のタグが含まれていると出力されない)
    • gc*: gcを含む全ての行が出力される (他のタグが含まれていても出力される)
    • gc.heap*: gcとheapの両方を含む全ての行が出力される (他のタグが含まれていても出力される)
  • p.373 と違って、p.119 (5.3.6 の using unified logging to look into the jpms の「# -Xlog:module*」の付近)で時間やログレベルが無いのは何故?
    • 省略された部分に含まれているのでは?

C.3 Defining where messages should go

C.4 Defining what messages should say

C.5 Configuring the entire logging pipeline

appendix D: Analyzing a project's dependencies with JDeps

D.1 Getting to know JDeps

D.2 Including dependencies in the analysis

D.3 Configuring JDeps’ output

D.4 Drilling deeper into your project’s dependencies

D.5 JDeps understands modules

  • D.1 にはパッケージ名詳細が出ているのに、D.5 で「not found」だけなのは何故か?
    • 「-summary」オプションを指定しているから。
  • 「slf4j-api」で「not found」が出ているのは何故か?
    • 「api」だから、必要でない依存もあるのではないか?
      • しかし module が not found の場合は起動しないのでは?
        • 依存関係を無視して起動することは可能?

appendix E: Targeting multiple Java versions with multi-release JARs

E.1 Creating a multi-release JAR

E.2 Internal workings of MR-JARs

E.3 Usage recommendations

E.3.1 Organizing the source code

  • JVMのバージョンによって異なるクラスを作成するのは管理が困難になりそうに思える。

E.3.2 Organizing the bytecode

E.3.3 When to use MR-JARs

(以上)

[戻る]