web-dev-qa-db-ja.com

Java ee機能をJava 9？

mavenを使用し、他の内部アーティファクトに依存するアーティファクトがあります。私は Java-9 に移行中です。コードをモジュール化せずに（つまり、名前のないモジュール内で）すべてをJava 9に最初に移行する予定です。

私が遭遇する問題は、デフォルトのモジュールに含まれていないJava.xml.bindに依存していることです。 MavenでJava.xml.bindへのこの依存関係を表現する「正しい」方法はありますか？

javamavenjaxbjava-9jigsaw
19
Kevin Peterson

モジュールシステム は、クラスパスからアプリケーションをロードする場合のように、名前のないモジュールがモジュールグラフを構築する方法を示しています。さらに、ドキュメント自体から：-

コンパイラが名前のないモジュールでコードをコンパイルするか、Javaランチャーが呼び出され、アプリケーションのメインクラスがクラスパスからアプリケーションクラスローダーの名前のないモジュールにロードされると、名前のないモジュールのルートモジュールのデフォルトセットは、次のように計算されます。

  • _Java.se_モジュールは、存在する場合はルートです。存在しない場合、アップグレードモジュールパス上のすべての_Java.*_モジュール、またはexports少なくとも1つのパッケージ（修飾なし）がルートであるシステムモジュール間。

  • アップグレードモジュールパス上のすべての_non-Java.*_モジュール、またはexports修飾なしの少なくとも1つのパッケージであるシステムモジュール間もすべてルートです。

それ以外の場合、ルートモジュールのデフォルトセットはフェーズに依存します。

  • コンパイル時には、通常、コンパイルされるモジュールのセットです（これについては以下で詳しく説明します）。

  • リンク時には空です。そして

  • 実行時には、_--module_（または略して-m）ランチャーオプションで指定されたアプリケーションのメインモジュールです。

特定のプラットフォーム、ライブラリ、またはサービスプロバイダーモジュールがモジュールグラフに存在することを保証するために、デフォルトのルートセットにモジュールを追加することが必要な場合があります。どのフェーズでもオプション

--add-modules <module>(,<module>)*ここで_<module>_はモジュール名であり、指定されたモジュールをルートモジュールのデフォルトセットに追加します。

jetty.project で同様の問題が発生しましたが、同じものについて議論されたjdkメーリングリストの thread を使用し、修正を使用しました：

_--add-modules Java.se.ee
_

すべてのJava SEモジュールへのアクセスを提供し、あなたの場合は単に：

_--add-modules Java.xml.bind
_

これをMavenで使用するには、同じものを_maven-compiler-plugin_に埋め込みます。

_<compilerArgs>
    <arg>--add-modules</arg>
    <arg>Java.xml.bind</arg>
</compilerArgs>
_

zhekaKozlovが示唆するとおり here 。

注意すべき重要な点は、APIの非推奨をマークすることは、おそらくその使用を避けたいことを意味するということです。この方法に適応するには、おそらく _jaxb-api:2.3.0_ の依存関係の消費を開始できます。これはモジュールとしてロードでき、クラスパスからも実行できます。必要な変更は、依存関係リストに次を追加することです。

_<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.0</version>
</dependency>
_

Update：-最終的には、Java-10がすでに出ており、次にJDK/11がリリースされると、理想的には JEP 320：Java EEおよびCORBAモジュール を削除し、そのような依存関係をスタンドアロンライブラリに置き換えます。

21
Naman

はい、渡す必要があります--add-modules to Javaコンパイラ：

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.7.0</version>
    <configuration>
        <release>9</release>
        <compilerArgs>
            <arg>--add-modules</arg>
            <arg>javax.xml.bind</arg>
        </compilerArgs>
    </configuration>
</plugin>

その後、プロジェクトは正常にコンパイルされます。

11
ZhekaKozlov

JAXBは、Java EE（JAX-WS、JAF、JTA、およびいわゆる「共通注釈」）と共有される他のAPIとともに、Java SE 9で非推奨になり、 Java SEおよびJDKの将来のリリースで削除されることが提案されています。これらの各APIには、スタンドアロンバージョン/ダウンロードがあります。各APIには、それを維持する独自のJSRもあります。 JDKに含まれているAPIからスタンドアロンバージョンへの移行は、もちろん少し混乱を招くでしょう。

これらのAPIをJava SEおよびJDKから削除するための最初のステップは、これらのAPIを含むモジュールをデフォルトで解決しないことです。 JDK 9を使用してクラスパスでコードをコンパイルまたは実行すると、最初はAPIが存在しないように見えます。別の回答に記載されているように、簡単な回避策は、--add-modules Java.xml.bindでコンパイルまたは実行することです。そのCLIオプションは「Java.xml.bind」モジュールをルートモジュールのセットに追加して起動時に解決します。このモジュールはJDKランタイムイメージに含まれているため、JDK 9で動作します。

迅速な回避策を超えて、JAXBを使用するアプリケーションまたはライブラリは、スタンドアロンバージョンのAPI /実装の使用に移行する必要があります。 JAXB 2.3.0はまもなくMaven Centralに公開され、JDK 9以降で動作するように変更されています。スタンドアロンバージョンは、他のJARファイルと同様にクラスパスにデプロイできます。最終的には、スタンドアロンバージョンを（アップグレード）モジュールパスに展開し、モジュールとして使用することも可能になります。 JDK 9移行ガイドには、JAXBまたはJava EEと共有される他のAPIを使用するコードを移行するためのオプションに関する詳細が記載されています。

7
Alan Bateman

さて、これが誰かを助けることを願っています。おそらく、Java 9または10をインストールしていて、このjavax.xml.bindエラーを回避できないことがわかった場合、おそらく= Java 8経由でjenvフォルダーごと（本当にあいまいになって申し訳ありませんが、それが私が持っているすべてです現時点での時間）？

しかし、Java_HOMEの正しい設定を追加すると、MacOS上のexport Java_HOME="$(/usr/libexec/Java_home -v 1.8)"という問題が修正されました。

0
Brett Tofel