--- schema_version: "1" id: 047f653c7647350efef1190135bc72baf1d20102a0af189570a67bcd177d19b2 title: カスタムコネクタのための Java のアップグレード (パートナー) collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/general/partner-connector-upgrade.md canonical_url: https://docs.mulesoft.com/jp/general/partner-connector-upgrade source_site: docs.mulesoft.com content_type: documentation content_hash: 4cfac90af5fc5a041ad859eaa3670377ce0bf165fc7d44a5aa84d16d455a1ad7 description: MuleSoft Documentation Site latest: true --- # カスタムコネクタのための Java のアップグレード (パートナー) Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了します。Java 8 または 11 上で実行中のアプリケーションのアップグレードパスを計画します。
このガイドは MuleSoft パートナーにのみ適用されます。MuleSoft ユーザーの場合は、カスタムコネクタのための Java のアップグレード (顧客)を参照してください。
Java 17 用のカスタムコネクタをアップグレード、テスト、リリースして、MuleSoft エコシステム内で互換性を確保します。互換性のないコネクタを実行すると、ランタイムエラー、パフォーマンスの低下、セキュリティの脆弱性につながり、アプリケーションの安定性に影響する可能性があるため、この互換性を確保することが重要になります。 ## [](#始める前に)始める前に Java 17 用のカスタムコネクタをアップグレードしてテストする前に、次の考慮事項について理解しておく必要があります。 - 対象コンパイルレベル Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトをコンパイルできます。Java 17 以下では、追加の連動関係をコンパイルする必要があります。 Java 17 でコンパイルする場合、​`mule-modules-parent`​ をバージョン 1.9.0 以降にアップグレードします。コネクタの最小 Mule バージョンも 4.9.0 になるため、Mule 4.9.0 以降との互換性のみが確保されます。​`META-INF/mule-artifact/mule-artifact.json`​ の ​`minMuleVersion`​ が 4.9.0 以降であることを確認します。​[「Specify Java Compatibility (Java の互換性を指定する)」](https://docs.mulesoft.com/mule-sdk/latest/java-version-support#specify-java-compatibility)​を参照してください。 `mule-modules-parent`​ が 1.9.0 より前のバージョンである場合、コネクタのバイトコードレベルとその追加の連動関係は Java 8 に対応している必要があります。Java 11 または Java 17 の言語機能は使用できません。 - サポートされていないディレクティブ `-add-opens`​ または ​`-add-export`​ ディレクティブは設定しないでくださいください。これらのディレクティブは CloudHub または Runtime Fabric では許可されず、すべての環境でコネクタごとに管理する必要があります。また、後方互換性の負担が生じ、今後の Java アップグレードが複雑になり、セキュリティの脆弱性が生じる可能性があります。 - 最小 Mule バージョン カスタムコネクタが Mule 4.5.x 以前で実行されている場合、​`MuleArtifactFunctionalTestCase`​ を拡張する Java 17 テストは実行できませんが、Java 8 テストは引き続き実行できます。 テストを実行するときに最小 Mule バージョンを切り離すには、​`-Dmunit.jvm`​ パラメーターを追加して、​[Java 17 との互換性の直接テスト](#test-for-java-17-compatibility-directly)​の説明に従って Java 17 を使用します。 ## [](#upgrade-your-mule-sdk-connectors)カスタム Mule SDK Connector のアップグレード カスタム Mule SDK (Java SDK および XML SDK) Connector を Java 17 にアップグレードします。 ### [](#upgrade-third-party-libraries)サードパーティライブラリのアップグレード カスタムコネクタでサードパーティライブラリを使用している可能性があるため、Java 17 との互換性を確保することも重要です。カスタムコネクタがテストに合格しても、安全で信頼性のあるソフトウェアを提供することが引き続き重要になります。重要なバグや脆弱性が見つかった場合、修正されたバージョンにアップグレードする必要があります。Java 17 を明示的にサポートしている最新のライブラリを使用すると、ベンダーがそれらをすでに Java 17 でテストしているため、このプロセスが容易になり、信頼性が高まります。 カスタムコネクタのサードパーティライブラリをアップグレードして、Java 17 と互換性があるようにします。 - Java EE ライブラリ Mule 4.6.x では、以前の Mule バージョンとは異なる方法で Java EE ライブラリが公開されます。BOM 連動関係をカスタムコネクタに追加し、該当する場合は、提供された競合するライブラリを除外する必要があります。また、ライブラリを BOM 連動関係に個別に追加することもできます。 ```java 4.6.0 org.mule mule-javaee-runtime-bom ${muleJavaEeBomVersion} pom import ``` 詳細は、[Java EE Libraries](https://docs.mulesoft.com/mule-sdk/latest/java-ee-libraries)を参照してください。 - 外部ライブラリ 外部ライブラリ (カスタムコネクタにバンドルされていないサードパーティライブラリ) をアップグレードします。例として、JDBC ドライバー、JMS ブローカークライアント、Groovy Runtime などがあります。次の例は、JDBC ドライバーの外部ライブラリ設定を示しています。 ```java @ExternalLib(name = "MySQL JDBC Driver", description = "A JDBC driver that supports connection to the MySQL Database", nameRegexpMatcher = "(.*)\\.jar", requiredClassName = "com.mysql.jdbc.Driver", coordinates = "mysql:mysql-connector-java:5.1.44") public class MySqlConnectionProvider implements ConnectionProvider { // } ``` 外部ライブラリを Java 17 と互換性のあるバージョンに更新する必要があります。 ### [](#review-your-code)コードのレビュー カスタムコネクタをコンパイルしたら、Java 17 でカスタムコネクタを実行できることを確認します。Java 11 では一部の制限に警告のフラグが付けられますが、Java 17 では失敗のフラグが付けられ、無効にすることができないため、コードのレビューを行うことが重要です。たとえば、Java 17 ではリフレクションがより制限されているため、コードをレビューして不正なアクションがないことを確認する必要があります。 コードのレビューに役立つように、Java 17 のさまざまな変更の詳細を確認してください。 - JDK 移行ガイド Java 8 から Java 17 への変更の完全なリストについては、 [「Oracle JDK 移行ガイド」](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A)​を参照してください。このガイドを使用してコードへの影響を評価します。 - Mule Runtime Engine Mule Runtime Engine で行われた Java 17 の変更についての詳細は、​[「Mule Runtime」](https://docs.mulesoft.com/jp/general/java-support#mule-runtime)​を参照してください。 - Java クラスのリフレクション Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避してください。Java 17 で動作する堅牢なテストスイートを用意します。Java 17 では、​`setAccessible(true)`​ メソッドのアクセスの変更が許可されていないため、このメソッドには特に注意してください。 - シリアル化 Java 17 の制限に対応するようにシリアル化コードを更新します。コードで Gson などのライブラリを使用してクラスをシリアル化している場合、JDK クラスへのリフレクティブアクセスが含まれる Data Transfer Object (DTO) の使用に切り替えます。シリアル化ライブラリが更新されていることを確認し、リフレクションへの依存を最小限に抑えるようにコードを調整します。詳細は、[Configure Custom Serializers](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers)を参照してください。 - ライブラリのアップグレード ライブラリを Java 17 と互換性のあるバージョンにアップグレードします。これには、バージョン 1.14.0 への ByteBuddy の更新、0.8.10 への Jacoco の更新、バージョン 2.x への SLF4J の更新が含まれます。CGLib を ByteBuddy で置き換えて、Groovy や JRuby などの他のライブラリへの更新がないかを確認します。すべての連動関係に Java 17 との互換性があることを確認し、ランタイムの問題を回避します。 - テストスイートの実行に伴う変更 テスト方法を Java 17 に適応させます。Mockito を使用する場合、Mockito では JVM クラスをモックできないことに注意してください。モッキング用のカスタム実装を考慮し、PowerMock から新しい Mockito バージョンに切り替えます。Java 17 の変更を処理するようにテストを更新し、非推奨になったメソッドを回避します。 - Java プラットフォームモジュールシステム (JPMS) JPMS は Java 9 で導入されました。この機能では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。 - 分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。 - `ResourceBundle の読み込みへの対処`​: `ResourceBundleProvider`​ や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。 - サードパーティライブラリの変更ログを分析して、JPMS に関連する Java 17 の互換性と変更を理解します。 ### [](#欠落しているコードの追加)欠落しているコードの追加 Java 17 ではリフレクションがより制限されているため、API オブジェクトにはセッターが必要になります。以前の Java 8 では、API オブジェクトには、DataWeave のすべてのアクセス可能なプロパティに対してデフォルトのコンストラクターと getter のみがあれば十分でした。DataWeave がリフレクションを使用することなくこれらのプロパティを書き込むことができるように、API オブジェクトには setter も必要になりました。 クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。 ## [](#upgrade-your-rest-sdk-connectors)カスタム REST SDK Connector のアップグレード REST SDK バージョン 0.8.0-RC4 を使用して、カスタム REST SDK Connector を Java 17 にアップグレードします。 REST SDK 0.8.0-RC4 では、Java 17 と互換性のあるコネクタが生成され、Java カスタマイズなしでビルドされた REST SDK 0.8.0-RC3 コネクタのみとの後方互換性が維持されます。バージョン 0.8.0-RC4 には、0.8.0-RC3 より前の REST SDK バージョンとの後方互換性はありません。 REST SDK Connector を Java 17 にアップグレードする場合、次の手順を実行します。 - Java カスタマイズを含む REST SDK バージョン 0.8.0-RC3 以前のコネクタの場合、REST SDK 0.8.0-RC4 を使用してコネクタを再生成し、すべての Java カスタマイズを移植します。 結果のコネクタでは、以前のバージョンのコネクタとの互換性が失われる可能性があります。 - Java カスタマイズを含まない REST SDK 0.8.0-RC3 以前のコネクタの場合、REST SDK 0.8.0-RC4 を使用してコネクタを再生成します。 結果のコネクタには以前のバージョンとの後方互換性があります。 REST SDK についての詳細は、 [「REST SDK」](https://beta.docs.mulesoft.com/beta-mule-sdk/mule-sdk/1.1/rest-sdk/rest-sdk-connectivity)​を参照してください。 ### [](#既存のカスタム-rest-sdk-connector-のアップグレード)既存のカスタム REST SDK Connector のアップグレード 以前に REST SDK を使用してコネクタを生成していて、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。 1. REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。 ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. REST SDK 上書き機能を使用して設定クラス (​`ConnectorNameConfiguration.java`​) を手動で作成する場合、アノテーションを追加する必要があります。 ```java import org.mule.sdk.api.annotation.JavaVersionSupport; import org.mule.sdk.api.meta.JavaVersion; @JavaVersionSupport({JavaVersion.JAVA_8, JavaVersion.JAVA_11, JavaVersion.JAVA_17}) public class YourConnectorConfiguration ``` 3. コネクタを再生成します。 ### [](#新しいカスタム-rest-sdk-connector-のアップグレード)新しいカスタム REST SDK Connector のアップグレード REST SDK を使用して新しいコネクタを生成し、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。 1. REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。 ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. Mule Runtime バージョンを 4.6.x にアップグレードします。 ## [](#upgrade-your-rest-connect-connectors)カスタム REST Connect Connector のアップグレード カスタム REST Connect Connector を Java 17 にアップグレードします。 REST Connect で Java 17 がサポートされるようになりました。REST Connect Connector は、REST Connect を使用して API 仕様から生成されます。コネクタを Java 17 互換にするには、API 仕様を Exchange に再パブリッシュします。​[「REST Connect Connector ジェネレーター」](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect)​を参照してください。
REST Connect に TLS のサポートが追加されました。時間を節約するために、Java 17 用に生成されたコネクタを更新するときに TLS を有効にし、コネクタの生成とアプリケーションのテストを 1 回だけ行えばいいようにします。
## [](#upgrade-your-custom-configuration-properties-providers)カスタム設定プロパティプロバイダーのアップグレード カスタム設定プロパティプロバイダーをアップグレードして Java 17 との互換性を確保するには、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用に切り替えて、​[「カスタムコネクタのリリース」](#release-your-custom-connector)​の説明に従って ​`@JavaVersionSupport`​ アノテーションを使用します。カスタムコネクタと同様に ​[カスタムコネクタのための Java のアップグレード (パートナー)](https://docs.mulesoft.com/jp/general/partner-connector-upgrade), just like with any custom connector. The example custom configuration properties provider mentioned in [Example: Mule SDK Module](https://docs.mulesoft.com/mule-runtime/latest/custom-configuration-properties-provider#example-mule-sdk-module)​ で説明されているすべての手順も実行する必要があります。「例: Mule SDK モジュール」に記載されているカスタム設定プロパティプロバイダーの例は、Java 17 をサポートするように更新されています。この例を参照して、カスタム設定プロパティプロバイダーを更新してください。変更されたコード (MUnit へのテストの移行を含む) がどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/410ee26d8b3c44adacb077e099f32886f99eb6be)​ を参照してください。 または、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用への切り替えに非常に多くの変更が伴う場合、カスタム設定プロパティプロバイダーの ​`ExtensionLoadingDelegate`​ 内で ​`ExtensionDeclarer`​ を使用して宣言を追加します。変更されたコードがどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/19d9d45cd52b0695f7b9c2b9019bae88f45fb228)​ を参照してください。 ## [](#test-your-custom-connector-with-mtf)MTF を使用したカスタムコネクタのテスト モジュールテストフレームワーク (MTF) を使用してカスタムコネクタをテストして、Java 17 との互換性を確保します。MTF の詳細については、 [「MTF」](https://beta.docs.mulesoft.com/beta-mtf/mule-sdk/1.1/mtf)​を参照してください。 ### [](#ビルドのセットアップ)ビルドのセットアップ すべてのサポートされる Java バージョン (Java 8、Java 11、および Java 17) に対してパイプラインが確実に動作するようにします。次の例は、すべてのサポートされる Java バージョンに対してテストを実行するように設定された単一のビルドパイプラインを示しています。ここで ​`default`​ は Java 17 に対応します。 ![単一のビルドパイプラインの例](/mulesoft/current/ja-jp/general/_images/single-build-pipeline.png) パイプラインでは、前のテストが失敗してもすべてのテストが実行されます。たとえば、パイプラインでは、Java 11 のテストが失敗しても Java 17 のテストが実行されます。 パイプラインに複数のテストが含まれていても、パイプラインには 1 つのコンパイルフェーズと、Java 8 を対象とする 1 つのリリースフェーズがあります。 ### [](#初期テストの実行)初期テストの実行 初期テストを実行し、カスタムコネクタに Java 17 との互換性があるかをテストします。カスタムコネクタコードを変更しながらテストの実行を継続することができます。 1. カスタムコネクタの ​`pom.xml`​ ファイルで、次の設定を含めるように munit-extensions-maven-plugin 設定を更新します (​`jacoco.version`​ プロパティは 0.8.10 以降である必要があります)。 ```xml -javaagent:${settings.localRepository}/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar=destfile=${session.executionRootDirectory}/target/jacoco-munit.exec ``` 2. MTF テストを実行してカバー率レポートを生成します。テストを実行するときに ​`-Dtest=none`​ および ​`-DfailIfNoTests=false`​ フラグを使用して、JUnit テストをカバー率レポートに含めないようにします。 カバー率レポートは ​`target/jacoco-munit.exec`​ で使用できます。 ### [](#カバー率レポートの表示)カバー率レポートの表示 カバー率レポートを表示して、カスタムコネクタのカバー率を確認します。Java 17 との互換性を高い確度で確保するには、80% 以上のカバー率が必要です。 1. IntelliJ IDEA を開きます。 2. **\[Run (実行)\]**​ > ​**\[Show Coverage Data (カバー率データを表示)\]**​ に移動します。 3. **\[Choose Coverage Suite to Display (表示するカバー率スイートを選択)\]**​ で、​`jacoco-munit.exec`​ がまだリストにない場合は追加します。 4. カバー率を参照して結果を分析します。 カバー率は、コネクタがどの程度テストされているかを反映します。回避すべき重要な問題は、コード内の不正なリフレクティブアクセスです。これを検出する唯一の方法は、​[コードのレビュー](#review-your-code)​またはテストを行うことです。80% 以上のカバー率を目指すことで、getter や setter などのより単純なコードに柔軟性を持たせることができるほか、すべての重要なビジネスロジックを徹底的にテストできます。 ### [](#jdeps-maven-プラグインの追加)JDeps Maven プラグインの追加 JDeps は、使用またはアクセスできなくなった JDK 内部 API の使用量を検出する静的コード分析用のツールです。詳細は、 [「OpenJDK wiki」](https://wiki.openjdk.org/display/JDK8/Java+Dependency+Analysis+Tool)​を参照してください。 JDeps Maven プラグインをカスタムコネクタの ​`pom.xml`​ ファイルに追加します。 ```xml org.apache.maven.plugins maven-jdeps-plugin 3.1.2 jdkinternals test-jdkinternals true ``` 使用またはアクセスできなくなった JDK 内部 API をカスタムコネクタで使用している場合、ビルドは失敗します。 JDeps Maven プラグインは JDK にバンドルされている JDeps ツールを使用しているため、​`JAVA_HOME`​ 値を変更して Java 8 と 11 の両方でビルドをテストします。各 Java バージョンでビルドを実行することで、信頼度がさらに高まります。 テストなしで JDeps Maven プラグインを実行するには、次のコマンドを使用します。 ```bash mvn clean install -Dtest=none -DfailIfNoTests=false -DskipTests=true ``` これにより、潜在的なテストの失敗や長いテスト実行時間に対処することなく、問題のあるライブラリや内部アクセスの問題の確認に集中することができます。 ### [](#java-17-との互換性のテスト)Java 17 との互換性のテスト Java 11 または Java 17 のいずれかで実行されている Java 17 との互換性をテストできます。 Java 11 で実行している場合、不正なリフレクティブアクセス用のパラメーターを追加することで、早期検証を実行できます。​[不正なリフレクティブアクセス用のパラメーターの追加](#add-a-parameter-for-illegal-reflective-access)​を参照してください。 Java 17 で実行している場合、Java 17 を直接テストできます。​[Java 17 との互換性の直接テスト](#test-for-java-17-compatibility-directly)​を参照してください。 #### [](#add-a-parameter-for-illegal-reflective-access)不正なリフレクティブアクセス用のパラメーターの追加 リフレクティブアクセスは Java 17 の互換性を破る変更の 1 つです。Java 11 のデフォルト動作を使用して MTF テストを実行する場合、MTF テストではリフレクティブアクセスの警告のみが記録されます。 Java 17 の動作に似せるには、​`--illegal-access=deny`​ JVM パラメーターを使用して MTF テストを実行します。これにより、MTF テストは、警告のみを記録するのではなく失敗します。このパラメーターは、Mule Runtime バージョン 4.2.0 以降で使用します。 カスタムコネクタの ​`pom.xml`​ ファイルをセットアップして各設定を含める手順は、次のとおりです。 1. 空のプロパティを追加します。 ```xml ``` 2. 次の設定を含めるように munit-extensions-maven-plugin 設定を更新します。 ```xml <_JAVA_OPTIONS>-XX:+PrintCommandLineFlags ${mtf.javaopts} ``` `--illegal-access=deny`​ パラメーターを使用して MTF テストを実行できるようになりました。bash スクリプトの例を次に示します (使用可能な最新の Mule Runtime バージョンで置き換えてください)。 ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmtf.javaopts="--illegal-access=deny" > ./target/test.log ``` MTF テストを実行したら、​`target/illegal-access.log`​ ファイルに移動して、動作が不正なクラスや連動関係がないかを確認します。 次のコマンドを使用して、カスタムコネクタの外部の既知の警告を除外することもできます。 ```bash cat target/illegal-access.log | sort | uniq | grep -Ev "org.mule.module.artifact|org.mule.metadata|org.mule.runtime|org.mule.service" ``` #### [](#test-for-java-17-compatibility-directly)Java 17 との互換性の直接テスト MTF テストを実行し、Java 17 に対してカスタムコネクタの互換性をテストします。 前述のとおり、すべてのサポートされる Java バージョンに対して実行される単一のビルドパイプラインを使用できます。メインのビルドパイプラインが不安定にならないように、Java 17 用の別の一時的なビルドパイプラインをセットアップすることもできます。Java 17 にアップグレードしたら、一時的なビルドパイプラインを破棄し、メインのビルドパイプラインに集中します。 1. `MUNIT_JVM`​ 変数で JVM インストールへのパスを設定します (これは自身でインストールする必要があります)。​`JAVA_HOME`​ を Java 8 に設定する必要もあります。 2. 次の MTF 連動関係がカスタムコネクタの ​`pom.xml`​ ファイルで設定されていることを確認します。 - munit 3.1.0 - munit-extensions-maven-plugin 1.2.0 - mtf-tools 1.2.0 - mule-maven-plugin 4.1.0 - mule-extensions-maven-plugin 1.6.0-rc1 これらの MTF 連動関係には 4.3.0 以上の Mule バージョンが必要です。MTF テストで 4.3.0 より前の Mule Runtime バージョンに対して検証を行わないようにするには、カスタムコネクタの ​`pom.xml`​ ファイルで次のコードを ​`munit-plugin`​ 設定に追加します。 ```xml [...] ${minVersion} false EE ``` Java 17 に対する MTF テストは Mule Runtime 4.6.0 以降でのみ実行できます。Mule Runtime 4.5.x 以前の場合、MTF テストは Java 8 と Java 11 に対してのみ実行できます。 MUnit 3.1 は Mule Runtime 4.3.0 以降とのみ互換性があります。コネクタに Mule Runtime 4.2.0 以前との互換性がある場合、MUnit バージョンを上書きする従来のプロファイルを作成する必要があります。 次の bash スクリプトを使用し、Java 17 に対してカスタムコネクタをテストします。 ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmule.module.tweaking.validation.skip=true \ -Dmule.jvm.version.extension.enforcement=LOOSE > ./target/test.log ``` 使用する Mule Runtime バージョンで mule-modules-parent のバージョンが決まります。たとえば、Mule Runtime 4.6.0 を使用する場合、mule-modules-parent 1.6.0 を使用する必要があります。マイナーバージョンは、Mule Runtime 4.1.0 と mule-modules parent 1.1.0、Mule Runtime 4.2.0 と mule-modules-parent 1.2.0 などのように対応関係を維持します。 Java 17 は Mule Runtime 4.6.0 以降でサポートされます。ただし、コネクタは Mule 4.3.0 と Java 17 の両方との互換性を同時に持つことができます。コネクタに Mule 4.3.0 との互換性が必要な場合、mule-modules-parent バージョンは 1.3.0 を超えることはできません。コネクタを Java 17 と互換性のあるものにするために、必ずしも mule-modules-parent 1.6.0 を使用する必要はありません。コネクタで Mule Runtime 4.6.0 のその他の機能を活用するには、特に mule-modules-parent 1.6.0 を使用する必要があります。 ### [](#テストの読み取り)テストの読み取り MTF テストを実行したら、ビルドの結果は次のいずれかになります。 - テスト失敗 Java 17 との互換性を確保するためにカスタムコネクタコードの変更が必要になる可能性があります。 - すべてのテストに合格 カスタムコネクタを大きく変更する必要がないか、テストスイートが十分に包括的ではないかのいずれかです。テストスイートを見直して、コードカバー率が適切であることと、テストシナリオおよびアサーションが単純すぎないことを再確認します。 ## [](#release-your-custom-connector)カスタムコネクタのリリース コードを更新し、テストが緑色になったら、カスタムコネクタの新しい Java 17 互換バージョンをリリースする準備が整いました。 1. Java 17 の互換性を伝えるには、カスタムコネクタの ​`mule-sdk-api`​ 連動関係を追加または最新バージョンにアップグレードして、カスタムコネクタの Java 互換性のメタデータを生成します。 ```xml org.mule.sdk mule-sdk-api 0.10.1 ``` 2. Java SDK の場合は、次に示すように ​`@Extension`​ アノテーションと同じクラスに ​`@JavaVersionSupport`​ アノテーションを追加して、​`JAVA_17`​ という値を含めます。
XML SDK Module は Java 17 と互換性があり、プロパティを自動的に継承するため、XML SDK についてのアノテーションを追加する必要はありません。
```java @Extension(name = "Database") @Operations(...) @JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17}) public class DatabaseConnector { .. } ``` Mule 4.5.0 以降では、​`@JavaVersionSupport`​ アノテーションを指定しないカスタムコネクタは Java 8 および Java 11 と互換性があると見なされます。 カスタムコネクタは、Java 17 のみと互換性があるとマークできます。ただし、採用や下位互換性の問題が存在しないことを確認する必要があります。 Mule アプリケーションをデプロイすると、Mule アプリケーションのすべてのモジュールに Java バージョンとの互換性があることが検証されます。互換性がないことがわかると Mule はエラーをスローし、アプリケーションはデプロイされません。
XML SDK ベースのコネクタに固有のエラーメッセージ (​Extension 'module-error-handler-plugin' does not support Java 17.Supported versions are: [1.8, 11]​ など) が表示された場合は、Mule アプリケーションに Java 17 と互換性のないコネクタがまだ含まれていることを意味します。このエラーを解決するには、Mule アプリケーションのすべてのコネクタをアップグレードして、Java 17 と互換性があるようにします。
コードが Java 17 と互換性があるが、Java 17 互換性を宣言しない場合でも、テストの実行は成功します。 カスタムコネクタのクイックチェックを実行する場合、またはすべての連動関係の準備ができていない場合は、次の引数を渡して、Java サポート宣言のハードチェックをスキップします。 ```bash -M-Dmule.jvm.version.extension.enforcement=LOOSE ``` 詳細は、[Java Version Support](https://docs.mulesoft.com/mule-sdk/latest/java-version-support)を参照してください。 ## [](#関連情報)関連情報 - [Java サポート](https://docs.mulesoft.com/jp/general/java-support)