スタートアップ(英語)
コミュニティ(英語)
トレーニング(英語)
チュートリアル(英語)
ドキュメント
API、AI、ツール (英語)
Java サポート
MuleSoft は Mule Runtime 4.6 から、Java の長期サポート (LTS) リリースケイデンスを採用しており、Java 17 LTS のサポートが追加されています。Java 17 にアップグレードすると、パフォーマンスの向上、言語レベルの機能強化、セキュリティ強化、拡張された API とライブラリといった多数の利点があります。
多くのサードパーティベンダーが Java 8 のサポートを終了するため、MuleSoft 製品スタックに影響があります。新しい LTS リリースケイデンスを採用することで、セキュリティ、コンプライアンス、パフォーマンスが向上します。
この変更は、現在サポート対象の Mule バージョンで実行されている Mule アプリケーションや、Mule Runtime 4.6 にアップグレードしたアプリケーションにはすぐには影響しませんが、早急にアップグレード計画を開始することをお勧めします。Java 17 のアップグレード計画には、インテグレーションアプリケーション、コネクタ (Anypoint Connector とカスタムコネクタ)、Mule ゲートウェイポリシー、API プロキシの評価を含みます。これらのコンポーネントはすべて Java に依存しています。
既存の Java 8 アプリケーションは、実行の基盤となっている Mule バージョンの延長サポートの終了に達するまで引き続き Java 8 で実行されます。
Mule Runtime の Java サポート
次の表に、Java 8、Java 11、Java 17 のサポートのタイムラインを示します。
| Mule バージョン | Java バージョン |
|---|---|
4.9 LTS |
17 |
4.9 Edge |
17 |
4.8 Edge |
8、11、17 |
4.7 Edge |
8、11、17 |
4.6 LTS |
8、11、17 |
4.6 Edge |
8、11、17 |
4.5 Edge |
8、11 |
| Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了するため、Java 8 または 11 で実行しているアプリケーションのアップグレードパスを適宜計画してください。 |
Mule 4.6.0 以降では、アプリケーションの実行がサポートされる最大バージョンは Java 17 です。Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトと追加の連動関係をコンパイルできます。Mule 4.9.0 より前のバージョンでは、Java 8 の Mule プロジェクトと追加の連動関係をコンパイルする必要があります。
連動関係 (mssql-jdbc など) を選択するときに、pom.xml の Java 8 または Java 17 と互換性のあるバージョンを設定します。互換性については、連動関係のドキュメントを参照してください。
Mule リリースケイデンスについての詳細は、Edge and LTS Releases for Muleを参照してください。
アップグレード手順
次の手順に従って、Java 17 にアップグレードします。
-
アップグレード前
-
現在のセットアップを確認して、何をアップグレードまたは削除する必要があるかを特定します (Java 17 でサポートされなくなったまたは非推奨としてマークされた Java 機能など)。
-
テスト、ロールバック戦略、アップグレード後の確認を含め、包括的なアップグレード計画を作成します。
-
Java 17 にアップグレードした場合のアプリケーションのパフォーマンスについて確認します。
-
オンプレミスの場合 (アップグレードの場合と同様に)、ダウンタイムをスケジュールし、関係者に通知して、ビジネスの中断を最小限に抑えます。
-
-
アップグレード
-
Mule Runtime 4.6 にアップグレードします。
-
Mule アプリケーション内で使用されているすべての Anypoint Connector およびモジュールとカスタムコネクタ、およびポリシーを Java 17 にアップグレードします。カスタム Java コードが含まれるコネクタには、Java 17 との互換性を確保するための追加の変更が必要です。
-
ポリシーをアップグレードします。カスタム Java コードが含まれるポリシーには、Java 17 との互換性を確保するための追加の変更が必要です。
-
API プロキシと Mule アプリケーションをアップグレードします。カスタム Java コードが含まれるプロキシには、Java 17 との互換性を確保するための追加の変更が必要です。
-
Anypoint Studio を 7.17 にアップグレードし、Studio プロジェクトレベルで対象 JVM を変更して JVM をアップグレードまたはダウングレードします。
-
Java 17 での DataWeave の更新内容を確認し、アプリケーションが引き続き適切に動作することを検証します。
-
本番に移行する前に制御された環境でアプリケーションをテストします。
-
Mule Maven プラグイン 4.1.1 以降を使用してアプリケーションをデプロイメントする場合、Java 17 を使用するようにデプロイメントを設定します。
-
-
アップグレード後
-
アプリケーションを監視して予期しない動作がないかを確認します。
-
関連するドキュメントを更新して、アップグレード中に実行された変更を反映します。
-
Mule Runtime
Java 17 の改善されたパフォーマンスとセキュリティを利用するには、Mule Runtime 4.6 以降にアップグレードしてください。
ベストプラクティスは次のとおりです。
-
スタンドアロン Mule インスタンスをアップグレードする。
-
Runtime Manager で管理されているオンプレミス Mule インスタンスをアップグレードする。
-
Mule アプリケーションのビルドに使用する Mule バージョンを更新する。
-
Mule 4.6 以降で実行する対象にアプリケーションをデプロイする。
Mule アプリケーション
現在実行中の Mule アプリケーションのほとんどを、Java 17 を使用するように更新してテストし、再デプロイできます。ただし、カスタム Java コードを実行しているアプリケーションとコネクタでは、それらのコンポーネントを認定するための追加作業が必要です。インテグレーションアプリケーションまたは Mule ゲートウェイポリシーとプロキシを Java 17 にアップグレードする前に、アプリケーションおよびポリシー内で使用されるすべての拡張機能、モジュール、コネクタを Java 17 に更新する必要があります。
|
Mule 4.6.0 以降では、アプリケーションの実行がサポートされる最大バージョンは Java 17 です。Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトと追加の連動関係をコンパイルできます。Mule 4.9.0 より前のバージョンでは、Java 8 の Mule プロジェクトと追加の連動関係をコンパイルする必要があります。 連動関係 ( |
| アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする前にポリシーをアップグレードしてください。 |
Java 17 のパフォーマンスに関する考慮事項
Java 17 では、MuleSoft 製品に重要なパフォーマンスに関する変更が行われています。Java 17 には、コードの実行速度を向上させる新しい JIT コンパイラーが含まれています。
アプリケーションのパフォーマンスを向上させるには、以下を参照してください。
メモリ管理
Java 17 は、Java 8 などの以前のバージョンとは異なる方法でメモリを管理します。Java 17 では、要求のレイテンシーが短縮され、より想定どおりに作業が実行されます。これを実現するために、異なるメモリ管理アプローチが採用されています。各アプリケーションに大きく依存しますが、場合によっては、Java 17 はヒープメモリに優先的にコミットします。
|
アプリケーションの最適な動作を確保し、Java 17 の改善点を効果的に活用するには、次のパフォーマンステストと監視を実施する必要があります。
|
アプリケーションがオンプレミスにデプロイされている場合:
-
ワークロードが Runtime Fabric で実行される場合は、少なくとも 1400 MB のメモリを 0.50 vCPU レプリカサイズに割り当てる必要があります。メモリ要件はアプリケーションごとに異なるため、この最小値はほとんどのアプリケーションに最適なメモリの割り当て設定です。
-
ワークロードがハイブリッド環境やスタンドアロン環境などのオンプレミスで実行される場合は、オペレーティングシステムのガベージコレクションアルゴリズムを調整する必要があります。
デフォルトの TLS 暗号化の選択
Java 11 以降を使用するサーバーで TLS を使用する場合、暗号化のプリファレンスはサーバーによって決定されます。クライアントでサポートされる暗号化リストは、優先度を決定するためではなく、絞り込むために使用されます。 「Use server cipher suites preference by default (JDK-8168261) (デフォルトでサーバー暗号化スイートのプリファレンスを使用 (JDK-8168261))」を参照してください。
サーバーを Java 8 から Java 11 以降にアップグレードすると、(クライアントでサポートされる暗号化リストに応じて) 暗号化の再ネゴシエーションが発生し、セキュリティとパフォーマンスのトレードオフに影響を与える可能性があります。
暗号化のデフォルト値を変更する場合は、「プロトコルと暗号化スイートの指定」を参照してください。
Anypoint Connector およびモジュール
Anypoint Connector およびモジュールは、Java 17 での実行が MuleSoft によって認定されています。各コネクタおよびモジュールの Java 17 サポートについての詳細は、該当する Mule 4 Connector またはモジュールのリリースノートを参照してください。
コネクタおよびモジュールの Java 互換性情報を調べる場所
すべての Anypoint Connector とモジュールが Java 17 互換になりました。使用しているコネクタのリリースノートで、Java 17 と互換性のあるコネクタバージョンを確認してください。
Java の互換性情報は、[Asset versions (アセットバージョン)] テーブルのコネクタとモジュールの Exchange の詳細ページにも表示されます。コネクタはリリース時に Java 17 互換としてタグ付けされるため、これが最新の互換性情報です。

Java 17 と互換性のあるコネクタおよびそれぞれのバージョンのリストは、 Java 17 と互換性のある Anypoint Connector を参照してください。
Anypoint Connector のアップグレード
MuleSoft によって提供された、標準 (カスタムコードなし) で使用されている Anypoint Connector をアップグレードする手順は、次のとおりです。
-
Runtime Manager で、コネクタを含む Mule アプリケーションを Mule Runtime 4.6 以降で実行するように更新します。
-
Anypoint Studio で、プロジェクトプロパティレベルで対象 JDK を変更します。
-
JDK 17 を選択すると、プロジェクト内のコネクタを更新するように自動的に促されます。
-
パッケージ化中に、選択した JDK バージョンと互換性のないコネクタがプロジェクトにある場合は、案内とアラートが表示されます。
-
Mule 4.6 以降で実行する対象にアプリケーションをデプロイする。プロジェクトの Java バージョンとデプロイメント環境に不一致がある場合、Runtime Manager はアラートを表示します。
コネクタにカスタムコードが含まれている場合は、カスタムコネクタを参照してください。
カスタムコネクタ
カスタムコネクタ (カスタム設定プロパティプロバイダーを含む) とは、MuleSoft のパートナーやユーザーがビルドしたコネクタなど、MuleSoft が開発および管理していないコネクタです。アプリケーションでカスタムコネクタを使用している場合は、Java 17 および Mule Runtime 4.6 以降で実行するようにコネクタを更新する必要があります。
MuleSoft パートナーの場合:
-
Mule アプリケーションで、以下から生成されたコネクタを更新します。
-
モジュールテストフレームワーク (ベータ) を使用してコネクタをテストします。
-
Mule 4.6 以降で実行する対象にアプリケーションをデプロイする。
MuleSoft ユーザーの場合:
-
Mule アプリケーションで、以下から生成されたコネクタを更新します。
-
MUnit を使用してコネクタをテストします。
-
Mule 4.6 以降で実行する対象にアプリケーションをデプロイする。
コネクタのカスタムコード
コネクタにカスタムコードがある場合や、サードパーティライブラリを使用している場合、そのカスタムコードを更新して Java 17 との互換性を確保する必要があります。
-
Java クラスのリフレクション
Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避してください。Java 17 で動作する堅牢なテストスイートを用意します。Java 17 では、
setAccessible(true) メソッドのアクセスの変更が許可されていないため、このメソッドには特に注意してください。 -
Java プラットフォームモジュールシステム (JPMS)
JPMS は Java 9 で導入されました。この機能では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。
-
分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。
-
ResourceBundle の読み込みへの対処:ResourceBundleProvider や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。 -
サードパーティライブラリの変更ログを分析して、JPMS に関連する Java 17 の互換性と変更を理解します。
-
-
JDK 移行ガイド
Java 8 から Java 17 への変更の完全なリストについては、 「Oracle JDK 移行ガイド」を参照してください。このガイドを使用してコードへの影響を評価します。
Anypoint Studio
Anypoint Studio (Studio) 7.17 以降、Mule アプリケーションが Mule Runtime 4.6 以降で実行されている場合、Studio プロジェクトレベルで対象 JVM を変更して JVM をアップグレードまたはダウングレードできます。
Studio 17 では、互換性に関する案内が提供されます。
-
アプリケーションをパッケージ化するときに、Studio 7.17 はリアルタイムの案内を提供し、互換性のないコネクタのバージョンやプロジェクトの不一致がある場合はアラートを表示して、デプロイメントの失敗を防ぎます。
-
新しいコネクタまたはモジュールをプロジェクトに追加するときに、コネクタまたはモジュールの各バージョンでサポートされる JVM バージョンが表示されます。
-
既存の Studio プロジェクトを Java 17 にアップグレードするときに、Studio は Exchange を自動的に検索し、アプリケーション内のどの拡張機能 (モジュールとコネクタ) をアップグレードすべきかを提案します。
-
Studio から CloudHub にアプリケーションをデプロイするときに、Runtime Manager はプロジェクトの Java バージョンとデプロイメント環境の不一致を検出します。たとえば、プロジェクトが Java 8 用にビルドされていて、対象環境が Java 17 の場合、Runtime Manager と Studio はデプロイメントの失敗を防ぐための案内を提供します。
ポリシー
MuleSoft に含まれる Mule ゲートウェイポリシーは、Mule Runtime 4.6 リリース以降の Java 17 と互換性があります。これらのポリシーは、2025 年 2 月まで Java 8 の標準サポートが提供されます。したがって、できるだけ早急にポリシーの更新を開始することをお勧めします。
| アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする前にポリシーをアップグレードしてください。 |
ポリシーをアップグレードする方法についての詳細は、「自動ポリシーのアップグレード」と「API レベルのポリシーのアップグレード」を参照してください。
API プロキシ
MuleSoft に含まれる API プロキシは、Mule Runtime 4.6 リリース以降の Java 17 と互換性があります。これらの API プロキシは、2025 年 2 月まで Java 8 の標準サポートが提供されます。したがって、できるだけ早急に API プロキシの更新を開始することをお勧めします。
| アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする前に API ポリシーをアップグレードしてください。 |
アップグレードの手順は、[Proxy type (プロキシ種別)] によって若干異なります。
-
基本エンドポイント:
-
基本エンドポイントを使用する場合は、適合したアプリケーションを Mule Runtime インスタンスにデプロイし、自動検出を使用して API Manager に接続します。詳細は、「Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定」を参照してください。
-
基本エンドポイント API インスタンスを使用してインスタンスを更新する場合は、API インスタンスに接続している Mule アプリケーションを更新します。
-
-
プロキシアプリケーション
プロキシアプリケーションをアップグレードする方法についての詳細は、「API プロキシのアップグレード」を参照してください。
Mule Maven プラグイン
Mule Maven プラグイン 4.1.1 以降を使用してアプリケーションをデプロイする場合、Java 17 を使用するようにデプロイメントを設定できます。
CloudHub にデプロイするときに、ビルドバージョンにメジャーバージョンとマイナーバージョンがある場合、Mule Maven プラグインはリリーストレインの最新ビルドバージョンをデプロイします。Mule Maven プラグインには、指定した Java バージョンに明示的にデプロイするための新しい Java バージョンプロパティがあります。
Runtime Fabric と CloudHub 2.0 にデプロイする場合、Mule Maven プラグインはビルドのタグ全体を受け入れるため、デプロイメントで正しいセマンティックバージョン (SemVer) を使用できます。
詳細は、次のドキュメントを参照してください。
DataWeave
DataWeave は、Java のリフレクション API を使用して Java オブジェクトの読み取りと書き込みを行います。Java 17 では、Java データ形式と Mule オブジェクトに影響する制限がカプセル化とリフレクティブアクセスに追加されています。
アプリケーションが引き続き適切に動作するようにするには、次のガイドラインに従ってください。
-
アプリケーションで使用されるオブジェクトが Plain Old Java Object (POJO) であることを確認する。
DataWeave 2.6.0 以降では POJO は必須です。Java 17 ではリフレクションがより制限されているため、POJO には setter も必要になりました。以前は、POJO には、すべてのプロパティに対してデフォルトのコンストラクターと getter がありました。DataWeave が Mule アプリケーションのコネクタの外部でビルドできるように、POJO には setter も必要になりました。
クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。
POJO に次の項目があることを確認する必要があります。
-
デフォルトのコンストラクター
-
すべてのプロパティの getter
-
すべてのプロパティの setter
-
-
定義済み変数が適切な API を介してアクセスされていることを確認する。
attributes、message、error などの変数には、特定のアクセス API があります。Java 17 を使用する場合は、内部項目にアクセスできなくなったため、適切な項目を使用する必要があります。次に例を示します。-
error.muleMessage は、適切な Mule エラー項目 error.errorMessage に置き換える必要があります。 -
error.errors は、適切な Mule エラー項目 error.childErrors に置き換える必要があります。
-
詳細は、次のドキュメントを参照してください。


