Contact Us 1-800-596-4880
  1. Homepage

  2. Java Support

Java Support

MuleSoft is adopting Java’s long-term-support (LTS) release cadence, beginning with Mule runtime 4.6, which adds support for Java 17 LTS. Upgrading to Java 17 provides many benefits, including improved performance, language-level enhancement, increased security, and extended APIs and libraries.

Many third-party vendors are discontinuing support for Java 8, which impacts the MuleSoft product stack. Adopting the new LTS release cadence provides greater security, compliance, and performance.

Even though this change has no immediate impact to Mule applications that are running on currently supported Mule versions, or on applications that are upgraded to Mule runtime 4.6, it is best to start your upgrade planning now. Java 17 upgrade planning includes evaluating integration apps, connectors (Anypoint connectors and custom connectors), Mule Gateway policies, and API proxies, as all of these components rely on Java.

Existing Java 8 apps will continue to run on Java 8 until the end of extended support for the Mule version they are running on is reached.

Mule Runtime Java Support

The following table shows the timeline for Java 8, Java 11, and Java 17 support:

Mule Version Java Version

4.9 LTS

17

4.9 Edge

17

4.8 Edge

8, 11, and 17

4.7 Edge

8, 11, and 17

4.6 LTS

8, 11, and 17

4.6 Edge

8, 11, and 17

4.5 Edge

8 and 11
Standard support for Java 8 and 11 ends in March 2025 for Mule 4.8 Edge and August 2025 for 4.6 LTS, so plan your upgrade path for apps that are running on Java 8 or 11 accordingly.

The maximum supported version for running your applications is Java 17 for Mule runtime 4.6.x and later. During the packaging of your app, all code, including third-party dependencies, must be compiled for Java 8.

For more information about Mule release cadences, see Edge and LTS Releases for Mule.

Steps for Upgrade

Follow these steps to upgrade to Java 17:

  • Pre-Upgrade

    1. Review your current setup to identify what needs upgrading or removal (such as any Java features that are no longer supported or are marked as deprecated in Java 17).

    2. Create a comprehensive upgrade plan, including testing, rollback strategies, and post-upgrade checks.

    3. Learn about application performance when upgrading to Java 17.

    4. For on-prem (as with any upgrade), schedule downtime and inform stakeholders to minimize business disruption.

  • Upgrade

    1. Upgrade to Mule runtime 4.6.

    2. Upgrade all Anypoint Connectors and modules, and custom connectors used within Mule apps and policies to Java 17. Connectors containing custom Java code need additional modifications to ensure compatibility with Java 17.

    3. Upgrade your policies. Policies containing custom Java code need additional modifications to ensure compatibility with Java 17.

    4. Upgrade your API proxies and Mule apps. Proxies containing custom Java code need additional modifications to ensure compatibility with Java 17.

    5. Upgrade Anypoint Studio to 7.17 and change the target JVM at the Studio project level to upgrade or downgrade the JVM.

    6. Learn about DataWeave updates for Java 17 and verify your apps continue to work as expected.

    7. Test your apps in a controlled environment before going live.

    8. If you are using Mule Maven plugin 4.1.1 and later to deploy your apps, configure the deployment to use Java 17.

  • Post-Upgrade

    1. Monitor your apps for any unexpected behavior.

    2. Update any relevant documentation to reflect changes made during the upgrade.

Mule Runtime

To take advantage of the improved performance and security of Java 17, upgrade to Mule runtime 4.6 or later.

Follow these best practices:

  • Upgrade your standalone Mule instances.

  • Upgrade on-premises Mule instances that are managed through Runtime Manager.

  • Update the Mule version used to build your Mule applications.

  • Deploy your applications to a target running on Mule 4.6 or later.

Mule Apps

You can update, test, and redeploy most of your currently running Mule apps to use Java 17. However, any apps and connectors that are running custom Java code require additional work to certify those components. Before you upgrade your integration apps or Mule Gateway policies and proxies to Java 17, you must update all extensions, modules, and connectors used within those apps and policies to Java 17.

The maximum supported version for running your applications is Java 17 for Mule runtime 4.6.x and later. During the packaging of your app, all code, including third-party dependencies, must be compiled for Java 8.
To ensure your API proxies or Mule apps are protected when upgrading, upgrade your policies before upgrading your API proxies or Mule apps.

Java 17 Performance Considerations

Java 17 provides important performance changes to MuleSoft products. Java 17 includes a new JIT compiler, which improves code execution speed.

To enhance application performance, see:

Memory Management

Java 17 manages memory differently than it did in earlier versions like Java 8. Java 17 reduces request latency and executes work more predictably. To achieve this, it adopts a different memory management approach. Although highly dependent on each application, in some cases, Java 17 preferentially commits to heap memory.

To ensure optimal operation of your apps and effectively leverage the Java 17 improvements, you must conduct performance testing and monitoring for:

  • Large batch apps

  • Apps that are at the limit of their CPU and memory offering

If your apps are deployed on-premises:

  • If your workloads run on Runtime Fabric, you must allocate at least 1400 MB of memory for 0.50 vCPU replica sizes. Because memory requirements vary for individual apps, this minimum provides the best memory allocation configuration for most applications.

  • If your workloads run on-premises, such as in a hybrid or standalone environment, you must tune your operating system’s garbage collection algorithm.

Default TLS Cipher Selection

When using TLS in a server with Java 11 and later, the server determines the cipher preference. The client supported ciphers list is used to filter, not to determine priority. See Use server cipher suites preference by default (JDK-8168261).

Upgrading your server from Java 8 to Java 11 and later can cause cipher renegotiation (depending on the supported ciphers list of the client), which can affect the trade-off between security and performance.

If you want to change the cipher’s default values, see Specify Protocols and Cipher Suites.

Anypoint Connectors and Modules

Anypoint Connectors and modules are certified by MuleSoft to run on Java 17. For information about Java 17 support for each connector and module, see the Release Notes for that Mule 4 connector or module.

Where to Find Java Compatibility Information for Connectors and Modules

All Anypoint Connectors and modules are Java 17-compatible now. Check the release notes for your connector to see which connector versions are compatible with Java 17.

Java compatibility information is also provided on the Exchange details page for connectors and modules in the Asset versions table. This is the most current compatibility information, as connectors are tagged as Java 17-compatible when they are released.

Expanded menu to show asset version detail option

For a list of Java 17-compatible connectors and their respective versions, see Java 17-Compatible Anypoint Connectors.

Upgrading Anypoint Connectors

To upgrade Anypoint Connectors that are provided by MuleSoft and being used out-of-the-box (no custom code):

  1. In Runtime Manager, update the Mule app that has your connectors to run on Mule runtime 4.6 or later.

  2. In Anypoint Studio, change the target JDK at the project property level.

  3. When you select JDK 17, Studio automatically prompts you to update the connectors in your project.

  4. During packaging, Studio provides guidance and alerts if there are any connectors in your project that are incompatible with the selected JDK version.

  5. Deploy your applications to a target running on Mule 4.6 or later. Runtime Manager shows alerts if there are any mismatches between the project’s Java version and the deployment environment.

If your connector includes custom code, go to Custom Connectors.

Custom Connectors

Custom connectors (including custom configuration properties providers) are any connectors that are not developed and maintained by MuleSoft, including connectors that are built by MuleSoft partners or customers. If you are using a custom connector in your app, you must update your connector to run on Java 17 and Mule runtime 4.6 and later.

If you are a MuleSoft partner:

  1. In your Mule app, update your connector that is generated from:

  2. Test your connector using Module Testing Framework (beta).

  3. Deploy your applications to a target running on Mule 4.6 or later.

If you are a MuleSoft customer:

  1. In your Mule app, update your connector that is generated from:

  2. Test your connector using MUnit.

  3. Deploy your applications to a target running on Mule 4.6 or later.

Anypoint Studio

Starting with Anypoint Studio (Studio) 7.17, if your Mule app is running on Mule runtime 4.6 or later, you can change the target JVM at the Studio project level to upgrade or downgrade the JVM.

Studio 17 provides compatibility guidance:

  • When you package your app, Studio 7.17 offers real-time guidance and alerts you if there are any incompatible connector versions or project mismatches to prevent deployment failures.

  • When you add a new connector or module to your project, Studio shows the supported JVM version for each version of the connector or module.

  • When you upgrade an existing Studio project to Java 17, Studio automatically searches Exchange and suggests which extensions (modules and connectors) in your app to upgrade.

  • When you deploy an app to CloudHub from Studio, Runtime Manager proactively detects mismatches between the project’s Java version and the deployment environment. For example, if your project is built for Java 8 and your target environment is Java 17, Runtime Manager and Studio provide guidance to prevent deployment failures.

For more information, see Selecting a Different Java Version to Run the Embedded Mule Runtime Engine and Update Your Modules.

Policies

The MuleSoft-included Mule Gateway policies are compatible with Java 17 beginning with the Mule runtime 4.6 release. These policies continue to have standard support for Java 8 until February 2025, so it’s best to start updating your policies as soon as possible.

To ensure your API proxies or Mule apps are protected when upgrading, upgrade your policies before upgrading your API proxies or Mule apps.

For details about how to upgrade your policies, see Upgrading Automated Policies and Upgrading API-Level Policies.

API Proxies

The MuleSoft-included API proxies are compatible with Java 17 beginning with the Mule runtime 4.6 release. These API proxies continue to have standard support for Java 8 until February 2025, so it’s best to start updating your API proxies as soon as possible.

To ensure your API proxies or Mule apps are protected when upgrading, upgrade your API policies before upgrading your API proxies or Mule apps.

The steps to upgrade are a little different, depending on your Proxy type:

  • Basic endpoint:

    • If you use Basic endpoint, deploy the adapted application to the Mule runtime instance and connect it to API Manager using autodiscovery. For more information, see Configuring Mule Gateway API Autodiscovery in a Mule 4 Application.

    • If you use a Basic endpoint API instance to update your instance, update the Mule application connecting to your API instance.

  • Proxy application

    For details about how to upgrade your proxy applications, see Upgrading API Proxies.

Mule Maven Plugin

If you are using Mule Maven plugin 4.1.1 and later to deploy your apps, you can configure the deployment to use Java 17.

When deploying to CloudHub, Mule Maven plugin deploys the latest build version of a release train when the build version has a major and minor version. Mule Maven plugin has a new Java version property to explicitly deploy to a specified Java version.

When deploying to Runtime Fabric and CloudHub 2.0, Mule Maven plugin accepts the entire tag of the build so you can use the correct semantic version (SemVer) in your deployment.

For more information, see the following documentation:

DataWeave

DataWeave uses Java’s reflection API to read and write Java objects. Java 17 adds some restrictions in encapsulation and reflective access that affect the Java Data Format and Mule objects.

To ensure that your applications continue to work as expected, follow these guidelines:

  • Verify that the objects used by your application are Plain Old Java Objects (POJOs).

    POJOs are required for DataWeave 2.6.0 and later. Because reflection is more restricted in Java 17, POJOs now require setters as well. Previously, POJOs had default constructors and getters for all properties. Now, POJOs must also have setters so DataWeave can build outside the connector in the Mule app.

    Constructors and setters are required if your class is instantiated by DataWeave, and getters are required if your class is read. If your class is returned and not instantiated, only getters are required. However, using both getters and setters simplifies the validation and certification process.

    You must ensure that the POJOs have:

    • A default constructor

    • Getters for all properties

    • Setters for all properties

  • Verify that predefined variables are accessed through their proper API.

    Variables like attributes, message, and error have specific access APIs. Using the proper fields is required when using Java 17 because internal fields are no longer accessible. For example:

    • error.muleMessage needs to be replaced by the proper Mule error field error.errorMessage.

    • error.errors needs to be replaced by the proper Mule error field error.childErrors.

For more information, see the following documentation:

See Also