JPMS

Java Platform Module System

jar ファイルの依存性をある程度管理でき、最小構成のJRE や実行パッケージが簡単に作れる。

かといってJDK 8をすぐ切り捨てられるわけでもないので別々のブランチなどで管理するかなというところ。

Maven でどう対応するか

MavenではgroupId, artifactId, version の3つでパッケージが管理されている。

version は記述方法に決まりがあり、リリース版のほか、SNAPSHOTなどが対応できるが、moduleの区別には使いづらい。

artifactId を変えることで対応するのもいいかもしれない。

SoftLib の場合

JDK 8用 groupId を net.siisise, artifactId を softlib としている。

module を LTS対応のJDK 11以降用として、 artifactId に .module をつける規則としてみた。最初 .java11 などを考えてみたがバージョンが出てくるのも微妙なので module としてみたり。

こうすることでバージョンは同じで扱え、グループも変わらず、artifactId の後ろに何かつくだけで区別できるのではないかな。

module-info.java

module名は、groupId + artifactId を使うか、代表 package 名を使うか、という感じにしておくと簡単。

SoftLib を省略して net.siisise を SoftLib のmodule名、net.siisise.abnf を SoftLibABNFのmodule名としてみたり。

module-info.java を省略した場合はjarファイル名からバージョン等を省いたものが仮のmodule名として使われる

exports このmoduleで外部に公開するjava パッケージ名を指定する

requires 使用する外のmoduleを指定する パッケージ名ではない

基本はこの2つ

サービスプロバイダ

moduleをJDBCドライバなどサービスプロバイダで拡張できる形で使いたい場合

module-info.java に provides, uses を記述することで対応できる

ドライバ側

provides 共通インターフェース with 実装クラス, 複数可;

META-INF/services/共通インターフェースのフルパスドット区切り に 実装クラス を書いていたのと同じ効果があるらしい。

利用する側

uses 共通インターフェース;

ServiceLoader で読み込む共通インターフェースだけ追加しておけばライブラリ内で使えるものを集めて利用できる。

テスト

Testパッケージ

こちらにもmodule-info.java が必要なようだがモジュール名は本体と同じ、ぐらいでいいらしい。

テスト用モジュールを追加する必要あり。