salesforce Dreamforce On-Demand
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.

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

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. Existing Java 8 apps will continue to run on Java 8 until February 2025.

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.

Mule Runtime Java Support

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

Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

4.6 LTS

February 2024

8, 11, and 17

February 2025

February 2026

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.8 Edge

October 2024

8, 11, and 17

February 2025

June 2025

4.9 LTS

February 2025

17

February 2026

February 2027

4.9 Edge

February 2025

17

June 2025

October 2025
Standard support for Java 8 and 11 ends with the Mule runtime 4.9 release in February 2025, so plan your upgrade path for apps that are running on either Java 8 or Java 11 accordingly.

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

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.

To ensure your API proxies or Mule apps are protected when upgrading, upgrade your API 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. Java compatibility information is also provided on the Exchange tiles for connectors and modules.

The most commonly used Anypoint Connectors and modules are Java 17-compatible now, and others are being released regularly. For a list of Java 17-compatible connectors, see Java 17-Compatible Anypoint Connectors.

To upgrade Anypoint Connectors:

  1. Update your Mule app to run on Mule runtime 4.6 or later.

  2. Change the target JVM at the project property level. This includes both upgrades and downgrades of the JVM version.

  3. In Anypoint Studio, update the connectors in your app to the latest Java 17-compatible version.

  4. 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 compile 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.

Custom Connectors

Custom connectors 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.

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 (MMP) 4.1.0 and later to deploy your apps, you can configure the deployment to use Java 17.

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

When deploying to Runtime Fabric and CloudHub 2.0, MMP 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.

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 6.0.0 and later, and you must ensure that the POJOs have:

    • A default constructor

    • Getters for all properties

    • Setters for all properties

For more information, see Java Format.

See Also