豆無日記スマートフォン用の表示で見る豆無日記この広告は、90日以上更新していないブログに表示しています。javaone2010Javaには膨大な数のライブラリがあり、我々開発者としてはそれらを使うことで既存の枯れた機能を簡単(?)に利用できてウハウハな訳ですが、ライブラリのJarファイルの管理はどうにも大変ですね。Jar同士の依存性管理とか、手動でがんばるとありえないし。いうわけで、今まではMavenやIvyなどの完全に外部のプロダクトとしてその辺りのソリューションが提供されてきてたわけですが、ついに本家による対策がなされるときがきたのです、というお話。組み込みではデファクトのモジュラリティソリューションであるOSGiをそのまま採用しよう↓やっぱりやめよう↓やっぱりOSGiでいこう↓(以下ループ)みたいなやりとりが過去にあったようです。結局はOSGiとは全然別物になって今回のお披露目となりました。Jigsawのセッションです。名前だけみると、なんかコスプレした人によく分からない場所に監禁されて致死確定のゲームを強いられるふいんきが漂いますが、もちろんそんなことはありません。Jigsawによる新しいモジュールシステムの特徴をぱらぱらと紹介していきます。間違いがありましたらツッコミお願いします。optimizations新しいモジュールシステムでは、実行時ではなく、Jarファイルを実行環境上にインストールするときに、色々と最適化しておくことで、実行時のロード時間を劇的に改善します。通常は実行時にクラスファイルのベリファイが行われますが、インストール時に実行しておくことで省略できるようになり、10〜20%程度高速になります。アプリケーション起動時にクラスのリストを記録して、それらを1つのファイルにコピーしておくことで、次回以降の起動が10〜30%程度高速になります。クラスファイルをより効率的なフォーマットに変換して、共有することで10〜20%程度高速化します。なんか数字だけ見るとめっちゃ速くなりそうなんですけど、実際どうなんですかね。modulesってことらしいです。Grouping複数のパッケージを1つのモジュールとして扱うための方法です。}のように、module-info.javaというファイルに、見慣れぬmodule記法でパッケージ名の共通部分までを記述すると、com.foo.Mainとcom.foo.Otherとcom.foo.ui.Shellが同一のcom.fooモジュールに含まれる、ということになります。com.foo.Main;}と書きます。Dependence次はモジュール内のクラスが外部ライブラリに依存してる場合です。....などと実行時にクラスパスリストをがんばって書かなければなりませんでしたが、Jigsaw以降はmodule-info.javaで宣言しておくだけOKになります。*1さて、module-info.javaは↓こう書きます。edu.baz.util;}パッケージ名を書くだけ。jarファイル名とかは気にしません*2。APIとしてのパッケージ名に対する依存性を記述します。Versioning依存先のAPIはバージョンごとに変化してしまう可能性がありますので、依存しているバージョンを明記するのは良い作法です。5.2_11;}このように@の後にバージョンを記述します。Encapsulation全部のモジュールがpublic扱いだと、見えすぎて何かとよくありません。Javaコードでも全部publicだとちょっとアレですね。適度に隠蔽した方が見通しもよくシンプルな構造が保てます。いうわけで、依存されるモジュール側でアクセスを許可するモジュールを指定して、限定公開することもできます。com.foo.lib;}と書くと、com.foo.libからのrequiresのみに限定することができます。com.foo.secret;}はそれ以外のモジュールからの依存になるのでNGです。なんかエラーになるんですかね。modulesもしあったら使うけど、無くても代替手段があるから別にいいよ、というオプション扱いのモジュールも指定できます。modules異なるモジュールを集約(Aggregation)した仮想モジュールを作ることもできます。packagesってことらしいです。代わりに、-modulepathオプションが提供されます。いえ、一応-classpathオプションも継続で提供されるようです。資料にあったコード例をみると、ここに指定したディレクトリにモジュールごとのクラスファイルが格納されるようです。この辺、実際に手を動かしてないので細かいところは不明です。次に、モジュールごとに、クラスファイルをjmodという形式でパッケージングします。jpkgというコマンドが追加されています。*.jmodcom.foo.app@1.0.0.jmodcom.foo.extra@0.9a.jmodcom.foo.lib@1.0.2.jmodというわけで、直下にjmodファイルができました。Librariesサードパーティから提供されているモジュールファイルをローカルのリポジトリにインストールして、自分のアプリからのモジュール依存性解決パスにいれる、などのようにモジュールをライブラリとして管理・利用するためにjmodコマンドが提供されています。jmodのコマンド例が資料にのってますが、説明文がないので解釈に全然自信がないです。↓のような話かと思われます・・・。アプリ専用のモジュールライブラリ(?)*3の格納用に、カレントディレクトリ配下のmlibディレクトリを生成します。createあらかじめとあるディレクトリにダウンロードしておいた、サードパーティのモジュールをインストールします。$EXT/org.bar.lib@*.jmod$前述の例において、自前で生成しておいたモジュールも同じくインストールします。*.jmodモジュールライブラリの中身を確認します。2.1-alpha-Lオプションでモジュールライブラリを指定しつつ、-mで実行したいmainメソッドを含むモジュールを指定して、アプリを起動します。...なお、$JRE/lib/modules配下に、以下のようなJREの標準モジュール群が格納されています。jdk.desktopjdk.xmljdk.basejdk.bootなどRepositoriesMavenリポジトリのように外部サーバに置いてあるjmodファイルをhttp経由で取得してインストールすることもできるよー、という話。packagesざっくり言うと、jmod形式だけじゃなくて、rpmとかdebとかOS依存のネイティブなパッケージ形式にも対応しているんだよー、という話。現状では、パッケージ間の依存性の図をかくと、50のノードと171の依存関係の線が引けます。これが、モジュラーシステムを導入すると、27のノードと95の依存関係になるそうです。