2017/05/20

JJUG CCC 2017 Spring

このエントリーをはてなブックマークに追加

Java Day Tokyo の後は、CCC です。前回の秋は出なかったので、1 年ぶり。

今回は、Project Jigsaw です。

しかし、今月になって Jigsaw の JSR 376Public Review Ballot が否決されてしまうと波乱があったばかり。こんな状態で、なんの話をすればいいのでしょう?

Ballot の意見を見ていても、結局は過去とのマイグレーションをどうすればよいかという点が指摘されています。OpenJDK の Jigsaw の ML でも、マイグレーション関連について活発に議論されています。

しかし、このあたりのことは Java Day Tokyo でのキーノートや Jigsaw のセッションでは一切触れられていませんでした。

そこで、このセッションでは発表時点で分かっていることはなるべく盛り込んで、話をしています。しかし、セッション後にやはり変更された点や追加議論が必要とされている項目も出てきています。

そういう点については、また稿をあらためて紹介できればと思っています。6 月の Public Review Reconsideration Ballot の後ですかね。

さて、発表資料はこちら。

すでに、ほぼ確定の module-info.java の書き方や、ビルド/実行の方法などについて触れた後、残りの 1/3 の時間を使ってマイグレーションについて話をしました。

特に既存の JAR ファイルをモジュールとして扱う Automatic Module について紹介しました。しかし、その Automatic Module が JCP での議論のトピックになっているわけです。とりあえず、セッションでは改定案を紹介しましたが、最終案がこうなるとはかぎりません。

あっ、1 点だけ、セッションで失敗したと思ったことが...

標準で提供されている Platform Module を調べるために java コマンドに --list-modules オプションがあります。これで調べた結果を示したのですが、JRE の java コマンドを使ってしまいました ><

JDK の java コマンドと JRE の java コマンドだと使えるモジュールも異なるのです。たとえば、jdk.jshell などは JDK の java コマンドだけです (もちろん、JRE でも --add-modules すれば使えます)。その点をすっかり忘れて、JRE でやってしまったのでした。

 

このセッションでは質問を受け付けるために sli.do というサービスを使いました。

Java Day Tokyo で @bitter_fox さんが、このサービスを使っていたので、私もまねしてみたわけです。

セッション中にオンラインで質問を投げられるし、それに対して「いいね」をすることもできます。なかなかいいですね、これ。次回も使ってみよう!!

というわけで、セッション中にいただいた質問をここで答えておきます。

 

Q. JASRACのひとがやってくる危険が危なくないですかww?

A. あー、あー、聞こえない、聞こえない

Q. mavenでは、moduleとどうやって整合とるのでしょう

A. Maven の動きをあまり追いかけていないのですが、問題となるのは Jigsaw のモジュールと artifacts が違うものだというこということにあると思います。どうやって折り合いをつけるかということは、まだ決まっていないようです。

プレゼンテーションにも登場させた Stephen Colebourne がこの件についてブログで言及しているので、ご参考までに。

Java SE 9 - JPMS modules are not artifacts

Q. メタ情報なのに.javaっていうのがちょっと嫌。JSONじゃダメなんだろうか。

A. Java で JSON を扱うのは意外に面倒なので... module-info.java を扱うのは javac なので、Java の構文解析がそのまま使えるのがいいのではないでしょうか。

プレゼン中にも言及しましたが、JSON-B が Java SE でも使えるようになったら変わるかもしれません。あくまでも個人的な意見ですが。

Q. moduleやrequires, exportsなどのキーワードはmodule-info.javaでのみ有効な予約語?の位置づけでしょうか

A. module-info.java のみで使用できる予約語です。

Q. モジュール化した場合としない場合でアプリの起動時間にどのくらい差がでてきますか?

A. 大きいシステムでモジュールを多くロードするようなシステムであれば差がでると思いますが、私自身は試してないのでよく分かりません。小さいシステムだと、それほど差がないように感じます。しかし、計測を行ったわけではないので、あくまでも感想レベルだと思ってください。

Q. module-info.javaが小文字始まりになった理由は何かあるのでしょうか

A. パッケージの情報を記述する package-info にならったのだと思います。

Q. // puckage export typo?

A. タイポはなかなか気がつかないので、ご指摘ありがとうございます! 公開している資料では修正してあります。

Q. モジュール版のmavenセントラルができることになるんですか?

A. 今のところそのような予定はないです。個人的には Maven セントラルが利用できれば一番いいのではないかと考えていますが、そのためには前述した artifacts とモジュールのすり合わせを行う必要があります。まだ、道は遠そうです。

Q. 昔、jarの中にjarを入れるsuper packageみたいな話があった気がしますが、そっちの話はどうなったのでしよう

A. JAR をまとめたパッケージングに関しては JSR 277 で JAM (Java Archive Module) というのが提案されていましたが、棄却されています。super package は言語側の拡張提案で、JSR 294 で提案されていましたが、こちらも棄却されました。これらを受け継いだのが、Project Jigsaw になります。

Q. Jigsawにはバージョンを管理する仕組みはないのでしようか? モジュール名にバージョン番号を入れる?

A. バージョンをつけることは可能です。バージョンをつけるには、jar コマンドの --module-version オプションで記述します。ただし、そのバージョンを使用して、バージョンを指定してビルドするなどは、現状ではサポートされていません。

Q. exportsで指定したパッケージのサブパッケージは公開されるのでしょうか?

A. 公開されません。公開するにはサブパッケージも exports 文を記述する必要があります。

Q. MANIFEST.MF に名前がなかったらどうするのでしょう

A. ファイル名が使われると思いますが、確認はしていません。

Q. testだけでパッケージを公開(exports, opens)したい場合やmoduleをrequiresしたい場合はどうするのが良いのでしょうか?

A. これは非常に難しい問題で、現状 Jigsaw では同じパッケージを複数のモジュールに分割することはできません。そのため、ファイルツリーを src と test に分割している (ビルドしたクラスファイルも別ディレクトリ) 場合はモジュールにしてしまうと、テストを実行することができません。

櫻庭もこれに対する最適解を見つけている最中なのですが、現状はテストの時はモジュールとして扱わないようにしています。コンパイルや実行に他のモジュールが必要な場合、--module-path と --add-modules オプションを使用して必要なモジュールをロードするようにしています。

0 件のコメント: