カスタムコネクタのための Java のアップグレード (パートナー)

このガイドは MuleSoft パートナーにのみ適用されます。MuleSoft ユーザーの場合は、カスタムコネクタのための Java のアップグレード (顧客)を参照してください。

Java 17 用のカスタムコネクタをアップグレード、テスト、リリースして、MuleSoft エコシステム内で互換性を確保します。互換性のないコネクタを実行すると、ランタイムエラー、パフォーマンスの低下、セキュリティの脆弱性につながり、アプリケーションの安定性に影響する可能性があるため、この互換性を確保することが重要になります。

始める前に

Java 17 用のカスタムコネクタをアップグレードしてテストする前に、次の考慮事項について理解しておく必要があります。

対象コンパイルレベル

アプリケーションの実行でサポートされる最大バージョンは、Mule Runtime 4.6.x 以降では Java 17 です。アプリケーションのパッケージ化中に、サードパーティの連動関係も含めて、すべてのコードを Java 8 用にコンパイルする必要があります。

Java 8 でカスタムコネクタをコンパイルする必要があるため、Java SDK の親 POM から Java コンパイラー設定を使用します。Java 11 または Java 17 の言語機能は使用できません。

コンパイルを Java 17 に変更した場合、関連するツール (Studio、Maven プラグイン、DataSense、接続テストなど) は引き続き Java 8 で実行されているため、機能しなくなります。

サポートされていないディレクティブ

-add-opens または -add-export ディレクティブは設定しないでくださいください。これらのディレクティブは CloudHub または Runtime Fabric では許可されず、すべての環境でコネクタごとに管理する必要があります。また、後方互換性の負担が生じ、今後の Java アップグレードが複雑になり、セキュリティの脆弱性が生じる可能性があります。
最小 Mule バージョン

カスタムコネクタが Mule 4.5.x 以前で実行されている場合、MuleArtifactFunctionalTestCase を拡張する Java 17 テストは実行できませんが、Java 8 テストは引き続き実行できます。

テストを実行するときに最小 Mule バージョンを切り離すには、-Dmunit.jvm パラメーターを追加して、Java 17 との互換性の直接テストの説明に従って Java 17 を使用します。

カスタム Mule SDK Connector のアップグレード

カスタム Mule SDK (Java SDK および XML SDK) Connector を Java 17 にアップグレードします。

サードパーティライブラリのアップグレード

カスタムコネクタでサードパーティライブラリを使用している可能性があるため、Java 17 との互換性を確保することも重要です。カスタムコネクタがテストに合格しても、安全で信頼性のあるソフトウェアを提供することが引き続き重要になります。重要なバグや脆弱性が見つかった場合、修正されたバージョンにアップグレードする必要があります。Java 17 を明示的にサポートしている最新のライブラリを使用すると、ベンダーがそれらをすでに Java 17 でテストしているため、このプロセスが容易になり、信頼性が高まります。

カスタムコネクタのサードパーティライブラリをアップグレードして、Java 17 と互換性があるようにします。

Java EE ライブラリ

Mule 4.6.x では、以前の Mule バージョンとは異なる方法で Java EE ライブラリが公開されます。BOM 連動関係をカスタムコネクタに追加し、該当する場合は、提供された競合するライブラリを除外する必要があります。また、ライブラリを BOM 連動関係に個別に追加することもできます。
```
<properties>
 <muleJavaEeBomVersion>4.6.0</muleJavaEeBomVersion>
</properties>
<dependencyManagement>
 <dependencies>
   <dependency>
     <groupId>org.mule</groupId>
     <artifactId>mule-javaee-runtime-bom</artifactId>
     <version>${muleJavaEeBomVersion}</version>
     <type>pom</type>
     <scope>import</scope>
   </dependency>
 </dependencies>
</dependencyManagement>
```
詳細は、Java EE Librariesを参照してください。
外部ライブラリ

外部ライブラリ (カスタムコネクタにバンドルされていないサードパーティライブラリ) をアップグレードします。例として、JDBC ドライバー、JMS ブローカークライアント、Groovy Runtime などがあります。次の例は、JDBC ドライバーの外部ライブラリ設定を示しています。
```
@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<Connection> {
  //
}
```
外部ライブラリを Java 17 と互換性のあるバージョンに更新する必要があります。

コードのレビュー

Java 8 でカスタムコネクタをコンパイルしたら、Java 17 でカスタムコネクタを実行できることを確認します。Java 11 では一部の制限に警告のフラグが付けられますが、Java 17 では失敗のフラグが付けられ、無効にすることができないため、コードのレビューを行うことが重要です。たとえば、Java 17 ではリフレクションがより制限されているため、コードをレビューして不正なアクションがないことを確認する必要があります。

コードのレビューに役立つように、Java 17 のさまざまな変更の詳細を確認してください。

JDK 移行ガイド

Java 17 で行われた変更の完全なリストについては、「Oracle JDK 移行ガイド」を参照してください。このガイドを使用してコードへの影響を評価します。
Mule Runtime Engine

Mule Runtime Engine で行われた Java 17 の変更についての詳細は、「Mule Runtime」を参照してください。
- Java クラスのリフレクション
  
  Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避する必要があります。堅牢なテストスイートがあり、Java 17 で動作することを確認します。
- シリアル化
  
  Java 17 の制限に対応するようにシリアル化コードを更新します。コードで Gson などのライブラリを使用してクラスをシリアル化している場合、JDK クラスへのリフレクティブアクセスが含まれる Data Transfer Object (DTO) の使用に切り替えます。シリアル化ライブラリが更新されていることを確認し、リフレクションへの依存を最小限に抑えるようにコードを調整します。詳細は、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 では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。
  - 分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。
  - ResourceBundle の読み込みへの対処: ResourceBundleProvider や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。

欠落しているコードの追加

Java 17 ではリフレクションがより制限されているため、API オブジェクトにはセッターが必要になります。以前の Java 8 では、API オブジェクトには、DataWeave のすべてのアクセス可能なプロパティに対してデフォルトのコンストラクターと getter のみがあれば十分でした。DataWeave がリフレクションを使用することなくこれらのプロパティを書き込むことができるように、API オブジェクトには setter も必要になりました。

クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。

カスタム 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」を参照してください。

既存のカスタム REST SDK Connector のアップグレード

以前に REST SDK を使用してコネクタを生成していて、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。

REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。

<parent>
   <groupId>com.mulesoft.connectivity</groupId>
   <artifactId>rest-sdk-connector-parent-pom</artifactId>
   <version>0.8.0-RC4</version>
</parent>

<rest.sdk.commons.version>0.8.0-RC4</rest.sdk.commons.version>
<rest.sdk.mojo.version>0.8.0-RC4</rest.sdk.mojo.version>

REST SDK 上書き機能を使用して設定クラス (ConnectorNameConfiguration.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

コネクタを再生成します。

新しいカスタム REST SDK Connector のアップグレード

REST SDK を使用して新しいコネクタを生成し、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。

REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。

<parent>
   <groupId>com.mulesoft.connectivity</groupId>
   <artifactId>rest-sdk-connector-parent-pom</artifactId>
   <version>0.8.0-RC4</version>
</parent>

<rest.sdk.commons.version>0.8.0-RC4</rest.sdk.commons.version>
<rest.sdk.mojo.version>0.8.0-RC4</rest.sdk.mojo.version>

Mule Runtime バージョンを 4.6.x にアップグレードします。

カスタム 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 ジェネレーター」を参照してください。

REST Connect に TLS のサポートが追加されました。時間を節約するために、Java 17 用に生成されたコネクタを更新するときに TLS を有効にし、コネクタの生成とアプリケーションのテストを 1 回だけ行えばいいようにします。

カスタム設定プロパティプロバイダーのアップグレード

カスタム設定プロパティプロバイダーをアップグレードして Java 17 との互換性を確保するには、Java SDK の使用に切り替えて、「カスタムコネクタのリリース」の説明に従って @JavaVersionSupport アノテーションを使用します。カスタムコネクタと同様にカスタムコネクタのための Java のアップグレード (パートナー), just like with any custom connector. The example custom configuration properties provider mentioned in Example: Mule SDK Module で説明されているすべての手順も実行する必要があります。「例: Mule SDK モジュール」に記載されているカスタム設定プロパティプロバイダーの例は、Java 17 をサポートするように更新されています。この例を参照して、カスタム設定プロパティプロバイダーを更新してください。変更されたコード (MUnit へのテストの移行を含む) がどのようなものかについては、この changeset を参照してください。

または、Java SDK の使用への切り替えに非常に多くの変更が伴う場合、カスタム設定プロパティプロバイダーの ExtensionLoadingDelegate 内で ExtensionDeclarer を使用して宣言を追加します。変更されたコードがどのようなものかについては、この changeset を参照してください。

MTF を使用したカスタムコネクタのテスト

モジュールテストフレームワーク (MTF) を使用してカスタムコネクタをテストして、Java 17 との互換性を確保します。MTF の詳細については、「MTF」を参照してください。

ビルドのセットアップ

すべてのサポートされる Java バージョン (Java 8、Java 11、および Java 17) に対してパイプラインが確実に動作するようにします。次の例は、すべてのサポートされる Java バージョンに対してテストを実行するように設定された単一のビルドパイプラインを示しています。ここで default は Java 17 に対応します。

単一のビルドパイプラインの例

パイプラインでは、前のテストが失敗してもすべてのテストが実行されます。たとえば、パイプラインでは、Java 11 のテストが失敗しても Java 17 のテストが実行されます。

パイプラインに複数のテストが含まれていても、パイプラインには 1 つのコンパイルフェーズと、Java 8 を対象とする 1 つのリリースフェーズがあります。

初期テストの実行

初期テストを実行し、カスタムコネクタに Java 17 との互換性があるかをテストします。カスタムコネクタコードを変更しながらテストの実行を継続することができます。

カスタムコネクタの pom.xml ファイルで、次の設定を含めるように munit-extensions-maven-plugin 設定を更新します (jacoco.version プロパティは 0.8.10 以降である必要があります)。

<argLines>
         <argLine>                      -javaagent:${settings.localRepository}/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar=destfile=${session.executionRootDirectory}/target/jacoco-munit.exec</argLine>
</argLines>

MTF テストを実行してカバー率レポートを生成します。テストを実行するときに -Dtest=none および -DfailIfNoTests=false フラグを使用して、JUnit テストをカバー率レポートに含めないようにします。

カバー率レポートは target/jacoco-munit.exec で使用できます。

カバー率レポートの表示

カバー率レポートを表示して、カスタムコネクタのカバー率を確認します。Java 17 との互換性を高い確度で確保するには、80% 以上のカバー率が必要です。

IntelliJ IDEA を開きます。
[Run (実行)] > [Show Coverage Data (カバー率データを表示)] に移動します。
[Choose Coverage Suite to Display (表示するカバー率スイートを選択)] で、jacoco-munit.exec がまだリストにない場合は追加します。
カバー率を参照して結果を分析します。

カバー率は、コネクタがどの程度テストされているかを反映します。回避すべき重要な問題は、コード内の不正なリフレクティブアクセスです。これを検出する唯一の方法は、コードのレビューまたはテストを行うことです。80% 以上のカバー率を目指すことで、getter や setter などのより単純なコードに柔軟性を持たせることができるほか、すべての重要なビジネスロジックを徹底的にテストできます。

JDeps Maven プラグインの追加

JDeps は、使用またはアクセスできなくなった JDK 内部 API の使用量を検出する静的コード分析用のツールです。詳細は、「OpenJDK wiki」を参照してください。

JDeps Maven プラグインをカスタムコネクタの pom.xml ファイルに追加します。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jdeps-plugin</artifactId>
    <version>3.1.2</version>
    <executions>
        <execution>
            <goals>
               <goal>jdkinternals</goal> <!-- verify main classes -->
               <goal>test-jdkinternals</goal> <!-- verify test classes -->
            </goals>
        </execution>
    </executions>
    <configuration>
        <failOnWarning>true</failOnWarning>
    </configuration>
</plugin>

使用またはアクセスできなくなった JDK 内部 API をカスタムコネクタで使用している場合、ビルドは失敗します。

JDeps Maven プラグインは JDK にバンドルされている JDeps ツールを使用しているため、JAVA_HOME 値を変更して Java 8 と 11 の両方でビルドをテストします。各 Java バージョンでビルドを実行することで、信頼度がさらに高まります。

テストなしで JDeps Maven プラグインを実行するには、次のコマンドを使用します。

mvn clean install -Dtest=none -DfailIfNoTests=false -DskipTests=true

これにより、潜在的なテストの失敗や長いテスト実行時間に対処することなく、問題のあるライブラリや内部アクセスの問題の確認に集中することができます。

Java 17 との互換性のテスト

Java 11 または Java 17 のいずれかで実行されている Java 17 との互換性をテストできます。

Java 11 で実行している場合、不正なリフレクティブアクセス用のパラメーターを追加することで、早期検証を実行できます。不正なリフレクティブアクセス用のパラメーターの追加を参照してください。

Java 17 で実行している場合、Java 17 を直接テストできます。Java 17 との互換性の直接テストを参照してください。

不正なリフレクティブアクセス用のパラメーターの追加

リフレクティブアクセスは Java 17 の互換性を破る変更の 1 つです。Java 11 のデフォルト動作を使用して MTF テストを実行する場合、MTF テストではリフレクティブアクセスの警告のみが記録されます。

Java 17 の動作に似せるには、--illegal-access=deny JVM パラメーターを使用して MTF テストを実行します。これにより、MTF テストは、警告のみを記録するのではなく失敗します。このパラメーターは、Mule Runtime バージョン 4.2.0 以降で使用します。

カスタムコネクタの pom.xml ファイルをセットアップして各設定を含める手順は、次のとおりです。

空のプロパティを追加します。
```
<mtf.javaopts></mtf.javaopts>
```

次の設定を含めるように munit-extensions-maven-plugin 設定を更新します。

<environmentVariables>
   <!-- Toggles the JDK17 style flag -->
   <_JAVA_OPTIONS>-XX:+PrintCommandLineFlags ${mtf.javaopts}</_JAVA_OPTIONS>
</environmentVariables>

--illegal-access=deny パラメーターを使用して MTF テストを実行できるようになりました。bash スクリプトの例を次に示します (使用可能な最新の Mule Runtime バージョンで置き換えてください)。

#!/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 ファイルに移動して、動作が不正なクラスや連動関係がないかを確認します。

次のコマンドを使用して、カスタムコネクタの外部の既知の警告を除外することもできます。

cat target/illegal-access.log | sort | uniq | grep -Ev "org.mule.module.artifact|org.mule.metadata|org.mule.runtime|org.mule.service"

Java 17 との互換性の直接テスト

MTF テストを実行し、Java 17 に対してカスタムコネクタの互換性をテストします。

前述のとおり、すべてのサポートされる Java バージョンに対して実行される単一のビルドパイプラインを使用できます。メインのビルドパイプラインが不安定にならないように、Java 17 用の別の一時的なビルドパイプラインをセットアップすることもできます。Java 17 にアップグレードしたら、一時的なビルドパイプラインを破棄し、メインのビルドパイプラインに集中します。

MUNIT_JVM 変数で JVM インストールへのパスを設定します (これは自身でインストールする必要があります)。JAVA_HOME を Java 8 に設定する必要もあります。
次の 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 設定に追加します。

<configuration>
	[...]
<runtimeConfiguration>
    <discoverRuntimes>
        <minMuleVersion>${minVersion}</minMuleVersion>
        <includeSnapshots>false</includeSnapshots>
        <product>EE</product>
    </discoverRuntimes>
</runtimeConfiguration>
</configuration>

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 に対してカスタムコネクタをテストします。

#!/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 との互換性を確保するためにカスタムコネクタコードの変更が必要になる可能性があります。
すべてのテストに合格

カスタムコネクタを大きく変更する必要がないか、テストスイートが十分に包括的ではないかのいずれかです。テストスイートを見直して、コードカバー率が適切であることと、テストシナリオおよびアサーションが単純すぎないことを再確認します。

カスタムコネクタのリリース

コードを更新し、テストが緑色になったら、カスタムコネクタの新しい Java 17 互換バージョンをリリースする準備が整いました。

Java 17 の互換性を伝えるには、カスタムコネクタの mule-sdk-api 連動関係を追加または最新バージョンにアップグレードして、カスタムコネクタの Java 互換性のメタデータを生成します。
```
<dependency>
   <groupId>org.mule.sdk</groupId>
   <artifactId>mule-sdk-api</artifactId>
   <version>0.10.1</version>
</dependency>
```
Java SDK の場合は、次に示すように @Extension アノテーションと同じクラスに @JavaVersionSupport アノテーションを追加して、JAVA_17 という値を含めます。

XML SDK Module は Java 17 と互換性があり、プロパティを自動的に継承するため、XML SDK についてのアノテーションを追加する必要はありません。
```
@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 サポート宣言のハードチェックをスキップします。

-M-Dmule.jvm.version.extension.enforcement=LOOSE

詳細は、Java Version Supportを参照してください。