マルチリリースJAR-悪いですか？

翻訳者から： プラットフォームをJava 11レールに翻訳することに積極的に取り組んでおり、Java 8/11の機能を考慮に入れて、Javaライブラリ（ YARGなど）を効果的に開発する方法を検討しています。 考えられる解決策の1つはマルチリリースJARですが、すべてがスムーズではありません。

Java 9には、マルチリリースJARと呼ばれる新しいJavaランタイムオプションが含まれています。 これはおそらく、プラットフォームで最も物議を醸す革新の1つです。 TL; DR：これは深刻な問題に対する曲がった解決策であることがわかりました 。 この投稿では、なぜそう考えるのかを説明し、本当に必要な場合にそのようなJARを構築する方法を説明します。

マルチリリースJARまたはMR JARは、JDK 9で導入されたJavaプラットフォームの新機能です。ここでは、このテクノロジーの使用に関連する重大なリスクと、Gradleを使用したマルチリリースJARの作成方法について詳しく説明します。それでもしたい場合。

実際、マルチリリースJARは、異なるバージョンのランタイムで作業するための同じクラスの複数のバリアントを含むJavaアーカイブです。 たとえば、JDK 8で作業している場合、Java環境はJDK 8のクラスバージョンを使用し、Java 9の場合はJava 9のバージョンが使用されます。同様に、Java 10の将来のリリース用にバージョンが作成された場合、ランタイムはJavaのバージョンではなくこのバージョンを使用します9またはデフォルトバージョン（Java 8）。

カットの下で、新しいJAR形式のデバイスを理解し、これですべてかどうかを確認します。

マルチリリースJARを使用する場合

• 最適化されたランタイム。 これは、多くの開発者が直面する問題の解決策です。アプリケーションを開発するとき、どの環境で実行されるかは不明です。 ただし、ランタイムの一部のバージョンでは、同じクラスの汎用バージョンを埋め込むことができます。 アプリケーションが実行されているJavaのバージョン番号を表示するとします。 Java 9の場合、Runtime.getVersionメソッドを使用できます。 ただし、これはJava 9以降でのみ使用可能な新しいメソッドです。 他のランタイム、たとえばJava 8が必要な場合は、java.versionプロパティを解析する必要があります。 その結果、1つの関数の2つの異なる実装ができます。

• 競合するAPI：API間の競合の解決も一般的な問題です。 たとえば、2つのランタイムをサポートする必要がありますが、そのうちの1つではAPIは非推奨です。 この問題には2つの一般的な解決策があります。

  
  
  
  
  
  
  
  1. 最初は反射です。 たとえば、VersionProviderインターフェースを指定し、次に2つの特定のクラスJava8VersionProviderおよびJava9VersionProviderを指定して、対応するクラスをランタイムにロードできます（2つのクラスから選択するためにバージョン番号を解析する必要があるのは面白いことです！）。 このソリューションのオプションの1つは、リフレクションを使用して呼び出されるさまざまなメソッドを持つ単一のクラスを作成することです。
  2. より高度なソリューションは、可能な場合はメソッドハンドルを使用することです。 ほとんどの場合、リフレクションは抑制的で不快であり、一般的にはそうです。
  
  
  

マルチリリースJARの既知の代替

2番目の方法は、よりシンプルで理解しやすい方法で、ランタイムごとに2つの異なるアーカイブを作成することです。 理論的には、IDEで同じクラスの2つの実装を作成し、それらを2つの異なるアーティファクトにコンパイル、テスト、および正しくパックすることがビルドシステムのタスクです。 これは、長年グアバまたはスポックで使用されてきたアプローチです。 しかし、Scalaのような言語にも必要です。 コンパイラーとランタイムには非常に多くのオプションがあるため、バイナリー互換性はほとんど実現できません。

ただし、別のJARアーカイブを使用する理由は他にもたくさんあります。

• JARは単なるパッキングの方法です。

クラスを含むアセンブリアーティファクトですが、それだけではありません。通常、リソースもアーカイブに含まれます。 リソース処理のようなパッケージには価格があります。 Gradleチームの目的は、ビルドの品質を向上させ、開発者が結果、テスト、ビルドプロセス全般をコンパイルするための待ち時間を短縮することです。 アーカイブがプロセスにあまりにも早く表示されると、不要な同期ポイントが作成されます。 たとえば、API依存クラスをコンパイルするために必要なものは、.classファイルのみです。 jarアーカイブもjar内のリソースも必要ありません。 同様に、Gradleテストを実行するにはクラスファイルとリソースのみが必要です。 テスト用のjarを作成する必要はありません。 外部ユーザー（つまり、公開時）のみが必要です。 ただし、アーティファクトの作成が必須になった場合、一部のタスクを並行して実行できず、アセンブリプロセス全体が禁止されます。 小規模なプロジェクトではこれが重要ではない場合、大規模な企業プロジェクトではこれが主な減速要因です。

• jarアーカイブは、アーティファクトであるため、依存関係に関する情報を保持できないことがはるかに重要です。

Java 9およびJava 8ランタイムの各クラスの依存関係が同じになることはほとんどありません。 はい、単純な例ではこれになりますが、大規模なプロジェクトではこれは当てはまりません：通常、ユーザーはJava 9機能のライブラリのバックポートをインポートし、それを使用してJava 8クラスのバージョンを実装します。異なる依存関係ツリーを持つ要素があります。 これは、Java 9で作業している場合、不要な依存関係があることを意味します。 さらに、クラスパスを汚染し、ライブラリユーザーの競合を引き起こす可能性があります。

最後に、1つのプロジェクトで、さまざまな目的のJARを作成できます。

• API用
• Java 8の
• Java 9の
• ネイティブバインディングあり
• など

依存関係の分類子を誤って使用すると、同じメカニズムの共有に関連する競合が発生します。 通常、 ソースまたはjavadocsは分類子としてインストールされますが、実際には依存関係はありません。

• 不整合を生成したくないので、ビルドプロセスはクラスの取得方法に依存すべきではありません。 言い換えると、マルチリリースjarを使用すると副作用があります。JARアーカイブからの呼び出しとクラスディレクトリからの呼び出しは、まったく異なるものになりました。 セマンティクスには大きな違いがあります！
• JARの作成に使用するツールによっては、互換性のないJARアーカイブがある場合があります！ 1つのアーカイブに2つのクラスオプションをパッケージ化するときに、それらが単一のオープンAPI（ jarユーティリティ自体）を持つことを保証する唯一のツールです。 これは、理由がないわけではありませんが、必ずしもアセンブリツールやユーザーが関与するわけではありません。 JARは、基本的にZIPアーカイブに似た「エンベロープ」です。 そのため、収集方法に応じて、さまざまな動作が発生するか、間違ったアーティファクトを収集する可能性があります（気付かないでしょう）。

個々のJARアーカイブを管理するより効率的な方法

開発者が個別のアーカイブを使用しない主な理由は、収集して使用するのが不便であることです。 ビルドツールのせいです。Gradleが登場する前は、これにまったく対処できませんでした。 特に、Mavenでこのメソッドを使用した人は、追加のアーティファクトを公開するために、弱い分類関数のみに依存できました。 ただし、 分類器はこの困難な状況では役に立ちません。 ソース、ドキュメント、javadocsの発行からライブラリオプションの実装（guava-jdk5、guava-jdk7、...）やさまざまなユースケース（api、fat jar、...）まで、さまざまな目的で使用されます。 実際には、 分類子の依存関係ツリーがメインプロジェクトの依存関係ツリーと異なることを示す方法はありません。 つまり、POM形式は根本的に壊れています。 これは、コンポーネントがどのようにアセンブルされるか、およびコンポーネントが提供する成果物を表します。 2つの異なるjarアーカイブ（すべての依存関係を含むクラシックjarとファットjar）を実装する必要があるとします。 Mavenは、明らかに間違っている場合でも、2つのアーティファクトに同一の依存関係ツリーがあると判断します！ この場合、これは明らかですが、状況はマルチリリースJARと同じです！

解決策は、オプションを正しく処理することです。 Gradleは、オプションに基づいて依存関係を管理することでこれを実行できます。 現在、この機能はAndroidでの開発に使用できますが、Javaおよびネイティブアプリケーション用のバージョンにも取り組んでいます！

バリアントベースの依存関係管理は、モジュールとアーティファクトが完全に異なるものであるという事実に基づいています。 同じコードは、異なる要件を考慮して、異なるランタイムで完全に機能します。 ネイティブコンパイルで作業する人にとって、これは長い間明白でした。i386とamd64向けにコンパイルし、 i386ライブラリの依存関係をarm64と干渉することは決してできません！ Javaのコンテキストでは、これは、Java 8の場合、クラス形式がJava 8に対応する「java 8」JARアーカイブのバージョンを作成する必要があることを意味します。このアーティファクトには、使用する依存関係に関する情報を含むメタデータが含まれます。 Java 8または9の場合、バージョンに対応する依存関係が選択されます。 それはとても簡単です（実際、ランタイムはオプションの1つのフィールドにすぎないためではなく、いくつかを組み合わせることができます）。

もちろん、これまでに過度の複雑さのためにこれを行った人はいませんでした。Mavenは、明らかに、そのような複雑な操作の実行を許可しません。 しかし、Gradleでは可能です。 Gradleチームは現在、使用するオプションをユーザーに伝える新しいメタデータ形式に取り組んでいます。 簡単に言えば、ビルドツールは、このようなモジュールのコンパイル、テスト、パッケージ化、および処理を処理する必要があります。 たとえば、プロジェクトはJava 8およびJava 9ランタイムで動作するはずですが、理想的には、ライブラリの2つのバージョンを実装する必要があります。 これは、2つの異なるコンパイラ（Java 8での作業時にJava 9 APIを使用しないため）、2つのクラスディレクトリ、そして最終的には2つの異なるJARアーカイブがあることを意味します。 また、ほとんどの場合、2つのランタイムをテストする必要があります。 または、2つのアーカイブを実装しますが、Java 9ランタイムでJava 8バージョンの動作をテストすることにします（これは起動時に発生する可能性があるためです！）。

このスキームはまだ実装されていませんが、Gradleチームはこの方向で大きな進歩を遂げています。

Gradleを使用してマルチリリースJARを作成する方法

しかし、この関数がまだ準備ができていない場合、どうすればよいですか？ リラックスして、同じ方法で正しいアーティファクトが作成されます。 上記の機能がJavaエコシステムに表示される前に、2つのオプションがあります。

• リフレクションまたは異なるJARアーカイブを使用する古き良き方法。
• マルチリリースJARを使用します（適切なユースケースがある場合でも、これは悪いソリューションになる可能性があることに注意してください）。

さまざまなアーカイブまたはマルチリリースJARを選択しても、スキームは同じです。 マルチリリースJARは基本的に間違ったパッケージです。オプションではなく、目標であるべきです。 技術的には、ソースレイアウトは個々のJARと外部JARで同じです。 このリポジトリでは、Gradleを使用してマルチリリースJARを作成する方法について説明します。 プロセスの本質を以下に簡単に説明します。

まず、開発者の悪い習慣の1つを常に覚えておく必要があります。アーティファクトが起動される予定の同じバージョンのJavaを使用してGradle（またはMaven）を実行します。 さらに、Gradleを起動するために新しいバージョンが使用される場合があり、以前のAPIレベルでコンパイルが行われます。 しかし、そうする特別な理由はありません。 Gradleでは、 Rossのコンパイルが可能です。 JDKの位置を記述し、コンパイルを別のプロセスとして実行して、このJDKを使用してコンポーネントをコンパイルできます。 さまざまなJDKを構成する最良の方法は、このファイルで行われているように 、環境変数を介してJDKへのパスを構成することです 。 次に、ソース/ターゲットプラットフォームとの互換性に基づいて、適切なJDKを使用するようにGradleを構成する必要があります 。 JDK 9以降、クロスコンパイルには以前のバージョンのJDKは必要ないことに注意してください。 これにより、新機能-releaseが作成されます。 Gradle はこの関数を使用し 、必要に応じてコンパイラを構成します。

もう1つの重要なポイントは、指定ソースセットです。 ソースセットは、一緒にコンパイルする必要があるソースファイルのセットです。 JARは、1つ以上のソースセットをコンパイルすることによって取得されます。 Gradleは、セットごとに適切なカスタムコンパイルタスクを自動的に作成します。 つまり、Java 8およびJava 9のソースがある場合、これらのソースは異なるセットになります。 これが、Java 9のソースコードセットで動作する方法であり、クラスのバージョンがあります。 これは本当に機能し、Mavenのように別のプロジェクトを作成する必要はありません。 しかし、最も重要なことは、この方法を使用すると、セットのコンパイルを微調整できることです。

1つのクラスの異なるバージョンを持つことの難しさの1つは、クラスコードが他のコードからほとんど独立していないことです（メインセットにないクラスとの依存関係がある）。 たとえば、そのAPIは、Java 9をサポートするために特別なソースを必要としないクラスを使用できます。同時に、これらすべての共通クラスを再コンパイルし、Java 9用にバージョンをパックしたくありません。特定のJDKのクラス。 ここで設定します ：Java 9のソースセットとメインセットの間に依存関係を追加して、Java 9のバージョンをコンパイルするときに、すべての共通クラスがコンパイルクラスパスに残るようにします。

次のステップは簡単です。ソースの主要なセットがJava 8 APIレベルでコンパイルされ、Java 9のセットがJava 9レベルでコンパイルされることをGradleに説明する必要があります。

上記のすべては、前述のアプローチの両方を使用するのに役立ちます。別個のJARアーカイブまたはマルチリリースJARを実装します。 投稿はこのトピックに関するものなので、GradleにマルチリリースJARを作成させる方法の例を見てみましょう。

jar { into('META-INF/versions/9') { from sourceSets.java9.output } manifest.attributes( 'Multi-Release': 'true' ) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このブロックは、MR JARに使用されるMETA-INF / versions / 9ディレクトリにJava 9のクラスをパックし、マニフェストでマルチリリースラベルを設定することを説明しています。

これで、最初のMR JARの準備ができました！

しかし、残念ながら、この作業はまだ終わっていません。 Gradleを使用した場合、アプリケーションプラグインを使用すると、 実行タスクを介してアプリケーションを直接実行できることがわかります。 ただし、Gradleは通常、作業量を最小限にしようとするため、 実行タスクはクラスディレクトリと処理中のリソースのディレクトリの両方を使用する必要があります。 マルチリリースJARの場合、JARはすぐに必要になるため、これは問題です。 そのため、プラグインを使用する代わりに、独自のタスクを作成する必要があります。これは、マルチリリースJARの使用に対する議論です。

そして最後になりましたが、クラスの2つのバージョンをテストする必要があることに言及しました。 この場合、Javaランタイムの-releaseトークンに相当するものがないため、VMのみを別のプロセスで使用できます。 アイデアは1つのテストだけを記述する必要があるが、Java 8とJava 9では2回実行されるというものです。これは、ランタイム固有のクラスが正しく機能することを確認する唯一の方法です。 デフォルトでは、Gradleは1つのテストタスクを作成し、JARの代わりに同じ方法でクラスディレクトリを使用します。 したがって、2つのことを行います。Java9のテストタスクを作成し、JARと指定されたJavaランタイムを使用するように両方のタスクを構成します。 実装は次のようになります。

 test { dependsOn jar def jdkHome = System.getenv("JAVA_8") classpath = files(jar.archivePath, classpath) - sourceSets.main.output executable = file("$jdkHome/bin/java") doFirst { println "$name runs test using JDK 8" } } task testJava9(type: Test) { dependsOn jar def jdkHome = System.getenv("JAVA_9") classpath = files(jar.archivePath, classpath) - sourceSets.main.output executable = file("$jdkHome/bin/java") doFirst { println classpath.asPath println "$name runs test using JDK 9" } } check.dependsOn(testJava9)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、タスクの開始時に、Gradleが目的のJDKを使用してソースの各セットをコンパイルし、マルチリリースJARを作成してから、両方のJDKでこのJARを使用してテストを実行することを確認します。 Gradleの将来のバージョンは、これをより宣言的に行うのに役立ちます。

おわりに

まとめると。 マルチリリースJARは、多くのライブラリ開発者が直面する実際の問題を解決する試みであることを学びました。 ただし、この問題の解決策は間違っているようです。 正しい依存関係管理、アーティファクトとオプションのリンク、パフォーマンスへの関心（できるだけ多くのタスクを並行して実行する機能）-これらすべてがMR JARを貧しい人々の解決策にします。 この問題はオプションを使用して正しく解決できます。 それでも、Gradleバリアントを使用した依存関係管理は開発中ですが、単純なケースではマルチリリースJARが非常に便利です。 この場合、この投稿は、これを行う方法、およびGradleの哲学がMaven（ソースセットとプロジェクト）の違いを理解するのに役立ちます。

最後に、マルチリリースJARが理にかなっている場合があることを否定しません。たとえば、アプリケーションが実行される環境（ライブラリではない）が不明な場合ですが、これはむしろ例外です。 この投稿では、ライブラリ開発者が直面する主な問題と、マルチリリースJARがそれらを解決しようとする方法について説明しました。 オプションとしての依存関係の正しいモデリングは、マルチリリースJARと比較して、パフォーマンスを改善し（きめ細かい並列処理により）、メンテナンスコストを削減します（予期しない複雑さを回避）。 あなたの状況では、MR JARも必要になる可能性があるため、Gradleがすでにこれを処理しています。 このサンプルプロジェクトを見て、自分で試してみてください。