Java 9のジグソーパズルプロジェクト。避けられないモジュール式の未来

毎年、Javaモジュール化プロジェクトについて耳にします。 私たちが待つたびに、私たちは発表に従います。 Jigsawの準備はほぼ完了していると言われていますが、リリースするたびに延期されます。 たぶん、これはそんなに単純なプロジェクトではないでしょう。 その変更がルートの開発に影響する可能性はありますか？ たぶん、モジュラーシステムは氷山の一角にすぎませんか？ Ivan KrylovにJigsawプロジェクトに関連する質問に答えるように依頼しました。



Ivanは10年以上にわたってJava仮想マシンとコンパイラを開発しており、現在、Azul SystemsのZing仮想マシンでコンパイラインフラストラクチャを開発しています。 JUG.ruカンファレンスおよびその他のヨーロッパのJavaカンファレンスで定期的に講演。

ジグソーとは何ですか？また、Javaの世界にどのように影響しますか？

-イワン、こんにちは。 JigsawプロジェクトがJavaエコシステムに与える影響を教えてください。



-いいね。 Javaとモジュール性についての私の見解を説明するために、私の仕事について少し話をする価値があります。 私は約20年間商用プログラミングに携わってきました。 それらの最後の11-仮想マシンの開発。 彼は、SunのHotSpot Runtimeチームで働いていました。 その後、同社はOracleに買収されました。 その後、アクティビティにいくつかの変更があり、過去3年半の間、仮想マシンを開発しているAzul Systemsで働いていました。



これらすべては、私の機能の見方は、JVM開発者、つまり「血なまぐさい企業」の世界から十分に遠い人であり、高レベルの抽象化の開発者が直面する問題だということです。



JigsawのJavaエコシステムへの影響の質問に戻りますが、最初はこの影響は見かけほど大きくありません。 そもそも、開発者がモジュールパラダイムに切り替えたくない場合、切り替えない可能性があります。 全体としてコードおよびスコープと対話する古い方法が機能します。 開発者がコードをモジュールに転送しようとしたときに問題が発生しますが、他のコードはまだモジュール式インフラストラクチャに移植されていません。



OSGiメカニズムを使用すると、他の問題が発生します。Jigsaw依存関係メカニズムに切り替えたい場合、これらの依存関係を記述する2つの方法を維持するのは難しいかもしれませんが、これらはさまざまな特殊なケースです。 一般的に、多くの開発者にとって、Jigsawプロジェクトは非常に目立たないように通過するため、おそらく世界中の誰にとっても普遍的な答えはありません。



-Java 8での主な革新は、ラムダ式とStream APIです。 Jigsawと比較して、どのような重要な変更点がありますか？



-Jigsawプロジェクトのモジュールは、コードの記述およびコードの機能シーケンスに大きな影響を与えません。 Jigsawは、さまざまなコンポーネント間の相互作用がどのように規定されるか、抽象化の単位でコードをどのようにラップするかを担当します。 Java 9では、革新的であるか、今日の開発者がコードを書く方法を大きく変える新しいAPIの計画はありません。



ある種の進化的な変更があります。たとえば、Java 8でOptionalが登場し、オプションのJava 9にStreamやthe または methodへのコンバータなどのいくつかのメソッドが追加されましたが、これらは増分変更です。 追加する必要があると感じました-追加しました。 プロセスAPIの大幅な変更。これにより、仮想マシンのPIDを見つけ、プロセスツリー、プロセス制御を取得できます。 Process APIを使用すると、ツイストする必要がある特定の数のハックを取り除くことができます。たとえば、解析出力または他のメソッドを使用したシェル呼び出し、ネイティブに入る別の必要性はなくなります。 このようなインクリメンタルな変更はクラスライブラリコード全体に散在していますが、APIにコードが1つも強力な構文が1つもありません。



すべてのセマンティックの変更は、 Milling Project Coinで収集されます。 最も顕著なのは、おそらくプライベート（デフォルト）インターフェースメソッドの外観です。 2つのプライベートインターフェイスメソッドに共通のコードが含まれている状況を想像してください。 以前は、このようなコードはパブリックメソッドにのみ転送できましたが、このインターフェイスが提供するパブリックAPIの観点からは、このようなメソッドは意味をなさない場合があります。 これで、このようなメソッドをプライベートとして宣言できます。 このメソッドは、このインターフェイスのAPIの一部として表示されませんが、これらのデフォルトメソッド内で実装を安全に使用できます。 この変更により、インターフェイスを使用して提供するAPIをよりクリーンにすることができ、特に、このインターフェイスのメソッドのデフォルト実装を提供できます。



-モジュール化プロジェクトは約9年前から存在しており、リリース日は複数回延期されています。 JavaOne 2015カンファレンスで、このトピックは複数のスピーカー（Alan Bateman、Alex Buckley、Mark Reinhold）によって表彰されました。 このような興奮は、プロジェクトの重要性を示していますか？



-Jigsawプロジェクトにより、特定の変更が行われました。 私はジグソーパズルをいくつかの2つの構成要素と考えています。1つ目は、可視性モデルの言語、モジュール宣言、構文の変更です。 2番目の部分は、モジュールモデルをjdkのクラスライブラリに直接適用した方法です。 一部のクラスは移動し、他のクラスは廃止されたか、外部から見えなくなりました。



大きな議論は、反射メカニズムについてでした。 以前は、プライベートクラスとメソッドに手を差し伸べることができました。 フィールドの変更は、リフレクションとプライバシーにより、オンザフライで実行できました。 つまり、多数のライブラリで使用されていたエクスプロイトが利用可能でした、と私は言います。 これは最終的にユーザーに影響します。 あなたがリストした言語アーキテクトはコミュニティに行き、どんな変化が起こるのか、なぜ起こるのか、なぜあなたはこれらの苦痛な変更をする必要があるのか​​について話しました。 痛みは、特定の数のライブラリーがすぐに自動的に非互換になることです。 彼らがコードをより互換性のあるバージョンに変換するのには時間がかかりますが、通常のように、たとえば「9番目のバージョンに切り替えるとすべてが壊れる」などのノイズが伴います。 これらの説明が必要でした。



昨年のジグソーに関する多数のレポートはJavaOneに関するもので、アントワープのDevoxxに関するレポートとほぼ同じでした。 レポートは同じになりますが、部外者からは興味深いものになります。たとえば、IBMの担当者は、モジュールに切り替えた後に生命があるかどうかを教えてくれます。 JavaOne 2016のビデオを楽しみにして楽しみにしています。



-新しいコンセプトはモジュールです。 モジュールの「コンポーネント」部分を正しく解釈する方法：モジュール名、エクスポート、および要求？ 「requires」について詳しく説明し、「requires local」や「requires optional」など、実際に「requires」できることを理解したいのですが。



-簡単な本の例から始めましょう。既存のコードがなく、ゼロから作成する状況です。 クラスがあり、それらを異なるパッケージに配置し、それらが密接な明確なコミュニケーションを持たないことを決定し、それらは異なるモジュールにあります。 最初のモジュールのクラスが2番目のモジュールのクラスを必要とする場合、私はそれが必要である、つまりrequireであると言い、このモジュールは2であり 、どのパッケージが必要かを示します。 パッケージがクラスレベルで抽象化を管理し、モジュールがパッケージレベルの階層を管理する場合、階層全体は非常に厳密です。これには expression が必要 です。



検証は、コンパイル時と実行時の両方で発生します。これは、Java言語の他の要素でよく発生するためです。 JVMは、すべてのチェックに合格したことを保証できません。正直に言って、コンパイルレベルでは、バイトコードはどこからでも来る可能性があるため、多くの点でjavacとJVMランタイムレベルの両方でチェックが複製されます。 このモジュールが機能するために必要なパッケージが使用可能であることを確認する必要があります。これらのパッケージは、モジュール2またはモジュール3にあります。 それらが順番に他のモジュールを必要とする場合、対応するモジュールから必要なすべてのパッケージが利用可能であることを作業の最初に文字通り検証するために、そのような推移的なチェーンが構築されます。



次に、 エクスポートは可視性のメカニズムです。 彼は、このモジュールがそのようなパッケージを他のモジュールに提供すると言っています。 すべての人が一度に条件付き「*」であることを指定できます。これは、このモジュールを使用する他のすべてのモジュールがパッケージを使用できることを示します。 これは、ユーザーが絶対にすべてのクラスにアクセスできることを意味するのではなく、パブリックと宣言されたクラスのみ、つまり エスケープされたものは、このメカニズムを通じて他のモジュールで利用可能になります。 指定したモジュールに直接エクスポートしたいときにエクスポートを指定できます。他の誰もこの静的宣言メカニズムを必要としません。



さらに、既にコンパイルされたモジュールの呼び出し時にこれらのスコープを変更できるようにする特定のランタイムフラグがあるため、モジュールを再構築する必要はありません。 作業を成功させるための十分なエクスポートがなかった場合、コマンドラインで追加できますが、理論的にはすべての宣言がモジュール内にあるため、これは中間段階と見なされます。 つまり モジュールは、このモジュールに必要なものとそうでないもの、および使用するために他のモジュールに提供するものを宣言した特定の完成したユニットです。



原則として、jdkライブラリのセット全体が明確な依存関係を持つモジュールのセットを表すように、jdk自体が再構築されています。 その結果、特定のサブセットjreを構築できます。この場合、必要なモジュールのみが存在します。 この点で、jlinkユーティリティが登場しました。これにより、必要なモジュールからのみランタイムイメージを構築できます。 これは、プロファイル付きのJava 8で登場したアイデアの明確な開発です。 jdk 8では、さまざまなクラスとさまざまな量の機能を備えたさまざまなプロファイルのjdkを構築できましたが、これは、たとえば、アプリケーションが本当に必要とするものをチェックせずに静的アセンブリです。 また、jlinkを使用すると、仮想マシン、java.baseモジュール、アプリケーションで必要な他のモジュールで構成されるポータブルランタイムを構築できます。



あるプレゼンテーションでは 、Java 9のモジュールに関する本の著者Paul BakkerとSander Makがさまざまな例を挙げました。 必要なランタイムを備えた単純なテキストアナラ​​イザープログラムのバージョンを組み立てました-約20メガバイトのディストリビューションを得ました。 スイングウィンドウがアプリケーションに追加されたとき、新しいモジュールが追加され、そのような配布のサイズは50メガバイトに増加しました。 JDKの内部にあり、jdkで提供されるモジュールに加えて、サードパーティのライブラリモジュールも追加できるため、JDKライブラリの境界は塗りつぶされています。 このような分布は、まったく異なる方法でまとめられます。 これにより、プログラムを新しい方法で再配布できます。顧客が新しいバージョンのjdkをダウンロードしてダウンロードする必要はなく、組み立てられたランタイムに直接配信する必要があります。



-「 依存性地獄 」の問題を永遠に忘れることはできますか？



-実際のプロダクションシステムでは、非常に多くのクラスパスが表示されることが多く、多数のjarがリストされるか、コンパイルされたコードが配置されるディレクトリが表示されます。 多くの場合、同じパッケージの同じクラスがクラスで宣言され、ランタイムはクラスパスに表示されていたものを使用します。 この点で、多くの人々はそのような問題に気づきました。クラスパスのjarの場所の変更によりプログラムの動作が変更されたとき、これはルートのモジュールの助けを借りて解決されます。



これは次のように発生します。クラスをパッケージに配置している場合、1つのパッケージで1つのモジュールを宣言できます。 したがって、たとえば、2つのjarに2つのモジュールがあり、両方にパッケージ要素が含まれている場合、パッケージは現在モジュールの1つに属していると想定されるため、この状況は不可能です。 各モジュールはパッケージを一意に宣言します。 同時に、ジグソーパズルはバージョン管理の問題を解決しません。 Linuxなどのパッケージマネージャーで見慣れている意味でのバージョンの対応。



モジュールのバージョン管理のタスクは、以前は以前のバージョンにありましたが、その後削除されました。できることは、バージョンをメタデータに書き込むことだけです。 このメタデータは抽出できますが、クラスローディングメカニズム自体は追加のチェックを行わず、OSGiなど他のパッケージマネージャーの手に委ねられます。 これは計算上の困難によるものです。 これは、クラスローダーが与えたくない複雑なタスクなので、外部ツールに転送されました。



-さまざまなタイプのモジュールが表示されます：名前付きモジュール、名前のないモジュール、自動モジュール。 それらについて簡単に話してもらえますか？ 彼らの違いは何ですか？また、誰もが全体的な構造に何をもたらしますか？



-すべてのルールに従ってモジュールを「最初から」記述する場合、つまり、モジュールの名前で最上位ディレクトリに置く場合、モジュールの宣言を含むmodule-info.javaファイルを追加します。このファイルには、ディレクトリの名前と一致する名前が必要です。 輸出をリストし 、を必要とします 。 このようなモジュールは、通常の名前付きモジュールです。



昔ながらの方法で生きていて、クラスパスを介して投げるだけのクラスがある場合、それらは名前のないモジュールと呼ばれるモジュールにもなります。 したがって、名前を付けなかったモジュールには、名前のない最後の避難所があります。これは、9つはモジュールなしでは機能できないためです。



ある中間段階があります。たとえば、jarファイルがあり、いくつかのパッケージが含まれている場合、クラスパスではなくモジュールパスに配置すると、ランタイムはこのファイルをjarという名前と一致するモジュールとして想像し始めます-fileを使用すると、Namedモジュールの場合と同様の操作を引き続き実行でき、それを参照できます。



たとえば、名前付きモジュールを開発している場合。 まだモジュール構造に変換されていないライブラリに依存している場合、このライブラリを含むjarをモジュールパスに配置できます。 自動モジュールになります。 これで、 module-info.java ： requiresを参照してから、 それに自動的に割り当てられたモジュールの名前を参照できます。



そして最後に、ここ数週間で行われた最後の変更であり、この提案が受け入れられるかどうかはまだ明確ではありません。 少し前に、リフレクションに特定の問題があることを既に述べました。以前に何かに手を差し伸べることができた場合、今では仮想マシンレベルで保護があり、新しいコンセプトが出現していますが、現在開発中であり、標準に落ちる可能性があります、これは保証されていませんが、弱いモジュールです。



弱いモジュールは、このモジュール内のコードがクラスを介して名前付きモジュール内のクラスへのリフレクションに到達できる中間状態であり、正しくエクスポートされていないクラスにさえ到達できますが、同時にそのようなモジュール自体はその機能を外部にエクスポートできません。 これは、この移行期間を通過するために特別に行われたもので、リフレクションを通過して内部コードに到達する必要がありますが、これは本来これを目的としていませんでした。



時間が経つにつれて、弱いモジュールの使用は無駄になり、おそらくデバッグの目的で残っていると思います。 自動モジュールと同様に、これはモジュール化されていないコードからモジュール化されたコードへの移行を可能にする中間メカニズムです。

OSGi対ジグソーパズル：ホリバーラはありません

-なぜOSGiはJavaのモジュール化に承認されなかったのですか？ あなたはマーク・ラインホールドに同意します：「OSGiモジュール層はコンパイル時に動作しません。 パッケージ化、展開、および実行中のモジュール性のみに対応します。 さらに、ライブラリおよびアプリケーションモジュールには便利ですが、Java SEプラットフォーム上に厳密に構築されているため、プラットフォーム自体のモジュール化に使用することはできませんか？」 OSGi /ジグソーインタラクション用のペンローズプロジェクトがあります。 （OSGiモジュラーレイヤーは、コンパイル時には機能しません。アーカイブ、デプロイ、または実行中のモジュール性のみを指します。また、OSGiの形式では、ライブラリおよびアプリケーションモジュールに役立ちますが、厳密に作成されるためJava SEプラットフォームに基づいており、そのプラットフォームを変調するために使用することはできません（著者の翻訳ノート）。



-私は具体的にOSGiを研究しましたが、なぜOSGiがジグソーパズルにならなかったのかについて一定の意見がありました。 表面上の最初の答えはマーク・ラインホールドによってマークされました：メカニズム自体はJava SE仕様の上に記述されています。JavaSEフラグメント、つまりモジュールを提供したい場合、OSGiメカニズムは役に立たないので、下位レベルで何かが必要です。 一般に、OSGiはクラスローディングメカニズムを介して機能します。つまり、最初に共通のOSGi環境クラスローダーが1つ表示され、次に各バンドルOSGiに独自のクラスローダーがあります。これにより、クラスの可視性が明確に区別されます。



Jigsawメカニズムは同様の機能を提供しますが、すでに仮想マシンレベルで実行されているため、仮想マシン自体のパフォーマンスにとっては十分に重要です。 仮想マシン内で、クラスがシーケンスを介してアドレス指定されるのは秘密ではありません：クラスローダー、次にパッケージとクラス名、このペアを介して。 また、パッケージとクラス名がそれに対応する特定の文字列リテラルである場合、クラスローダーは単にクラスをロードするオブジェクトへの参照です。 したがって、永続化の場合に分析するには、仮想マシンを完了し、次のブートでこのデータを回復しようとすると、この参照は意味を失い、クラスローダーには独自の文字列リテラルがありません。 これは、このような事前のスタイルでの作業の最適化に制限を課します。 そのため、Jigsawの開発者は、OSGiで行われていたように、クラスのロードメカニズムに基づいてこの可視性メカニズムのベースを放棄することにしました。 OSGiがこれを行ったのは、仮想マシンが提供するものから入手できる唯一のものであり、クラス解決メカニズムに干渉できないためです。



-OSGiとJigsawの実際の実装は異なるレベルにあることが判明しました。



「はい、絶対に正しい。」 ジグソーパズルは低レベルで実装されています。 幸運にも不幸にも。 おそらく、残念ながら、すでにOSGiを使用したことがある人たちにとっては。 ここで、何らかの方法で相互作用するか、2つの並行する依存関係の記述を維持するか、Penroseのようなプロジェクトを使用して同期する必要があります。 記述は、モジュール記述、依存関係のジグソー記述、およびOSGi記述を生成できるJSONスクリプトを使用して設定されます。 これらの2つの世界を横断する必要があり、現在OSGiを使用しているユーザーは、もう少し困難な生活を送っています。



-クラスローダーの動作にどのような変更が発生しますか？



-変更はそれほど大きくありません。 , , Bootstrap classloader, Extension classloader Application classloader, instance of URL classloader. Java 9 , Extension classloader Platform classloader , Extension , jdk, . Java 9 , , Bootstrap classloader, Platform classloader. , Application classloader, instance of URL classloader, instance . , , Gradle, , instance of URL classloader — . Gradle Jigsaw .



, , , Gradle, . , Application classloader'. .



, , , — .



, — , , , .. , Whole Program Optimization, , .. , jit- . , , Oracle ahead of time jmod, , . , , , .

: ,

— ?



— , Jigsaw , . , , - requires . , , , , «Hello World». -: requires exports. , , , , , , .



, , . IDE, , , .



, private -, . javac , , . , , , , class resolution, , , , . つまり , .



— , IDE «Jigsaw». , . ?



— , , , , module , StackOverflow Google , .



IDE: , IDEA, «», , Jigsaw. , IDE, , IDE , .. «».



— Jigsaw — «». , ?



— , OSGi, , , , , . , , , .



Java 8 jdep , jdk, Java 9 jar module-info.java , , , requires . Jdep module-info.java, , , .. , , jdep .



, , , .

---

Java 9 Joker 2016 Sander Mak, Java 9 Modularity O'Reilly, Java 9 Modularity in Action .



«» JVM Java 9 , , Joker 2016:

• JITコードのライフサイクル
• Javaからアセンブリーへ：ウサギの穴
• Elbrus上のJava
• HotSpot Internals：セーフポイント、NullPointers、およびStackOverflow
• JMM-
• G1 GC, G1 GC
• Native , Off-heap Java

– .