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

  2. Java Support

Java Support

Extended support for Java 8 and 11 ends in February 2027 for 4.6 LTS. Upgrade your apps that run on Java 8 or 11.

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’s 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’re 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.13 Edge

17

4.12 Edge

17

4.11 Edge

17

4.10 Edge

17

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

In Mule 4.6.0 and later, the maximum supported version for running your applications is Java 17. In Mule 4.9.0 and later, you can compile any Mule project and additional dependencies for Java 17 or lower. In versions earlier than Mule 4.9.0, you must compile any Mule project and additional dependencies for Java 8.

When selecting a dependency (for example, mssql-jdbc), configure the version compatible with Java 8 or Java 17 in the pom.xml. For information about compatibility details, refer to the documentation of the dependency.

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.

In Mule 4.6.0 and later, the maximum supported version for running your applications is Java 17. In Mule 4.9.0 and later, you can compile any Mule project and additional dependencies for Java 17 or lower. In versions earlier than Mule 4.9.0, you must compile any Mule project and additional dependencies for Java 8.

When selecting a dependency (for example, mssql-jdbc), configure the version compatible with Java 8 or Java 17 in the pom.xml. For information about compatibility details, refer to the documentation of the dependency.
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.

When running Mule applications on Java 17, you might observe heap memory patterns that differ from Java 8. For example, heap usage can remain at a higher baseline or not decrease immediately after load. This behavior is expected and reflects how Java manages memory. For more information, see Mule heap memory pattern differences between Java 17 and Java 8.

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.

Upgrading Mule Apps and Connectors with MuleSoft Vibes

MuleSoft Vibes provides the upgrade-mule-app skill, which upgrades a Mule app to a later Mule runtime version and Java version, including the Anypoint Connectors and modules that the app uses. The skill works with apps on Mule runtime 4.3 or later and Java 8 or later. For each connector, the skill finds the latest version that supports both the target Mule runtime version and the target Java version.

By default, the skill recommends the highest minor version in your current support channel (LTS or Edge), the latest patch, and the latest Java version that isn’t end of life. You can request a different Mule runtime version, but the skill doesn’t downgrade an app or target end-of-life Java versions. If your target switches between LTS and Edge, the skill warns you and asks you to confirm.

Before You Begin

Before you use the skill, make sure you have:

  • Anypoint CLI v4

  • The @salesforce/anypoint-cli-dx-mule-plugin plugin version 1.3.0 or later

  • Apache Maven 3.9.x

  • A pom.xml file and a mule-artifact.json file in the root of your project

  • Any parent POM files that your pom.xml references, available locally

When you use MuleSoft Vibes in Anypoint Code Builder, Anypoint Code Builder automatically installs or updates Anypoint CLI after you restart VS Code. If you use the skill with Claude Code or another agent, you must install Anypoint CLI manually. For details, see Using Skills with MuleSoft Vibes.

Start an Upgrade with MuleSoft Vibes

To start an upgrade, enter a prompt in the MuleSoft Vibes chat, such as Upgrade my app to Java 17, Move the runtime to 4.9, or Modernize this Mule app. MuleSoft Vibes activates the skill before it reads or edits any project files.

The skill runs in two phases:

  1. Plan: The skill analyzes your app and doesn’t change any project files. It:

    1. Validates the prerequisites, and confirms the Mule runtime and Java versions it detects in your project with you.

    2. Builds the app on its current versions as a baseline. If the baseline build fails, the upgrade doesn’t continue.

    3. Recommends an upgrade target, which you can accept or replace with another target.

    4. Checks that each connector is available on Exchange for the target Mule runtime and Java versions, and stops if a connector has no compatible version.

    5. Reviews your flows, custom Java code, DataWeave scripts, and MUnit tests for changes that the new versions require.

    6. Presents the complete upgrade plan in the chat, listing every change to your project. You choose to proceed, change the plan, or cancel.

  2. Execute: After you approve the plan, the skill:

    1. Updates your project files.

    2. Builds the app and runs your MUnit tests, and fixes any errors that result from the upgrade.

    3. Reports the build and test results, and the versions before and after the upgrade.

If a build or test error persists after several attempts, the skill asks you how to proceed.

Changes the Skill Makes to Your Project

After you approve the plan, the skill changes these files:

File Changes

pom.xml

  • Updates the Mule runtime and Java version properties.

  • Updates the Maven compiler level to the target Java version.

  • Updates the Mule Maven plugin and MUnit versions to the latest versions.

  • Updates the connector dependency versions.

mule-artifact.json

Updates minMuleVersion and adds the target Java version to javaSpecificationVersions.

Mule flow files in src/main/mule

Updates connector operations, attributes, namespace bindings, xsi:schemaLocation values, and error types that changed in the new connector versions.

Java files in src/main/java

Replaces removed or restricted Java APIs, such as javax.xml.bind classes, with supported alternatives.

MUnit test files in src/test/munit

Updates mocks, payload shapes, assertions, and error types to match the new connector versions.

Parent POM files

Updates connector versions that a parent POM defines. After a successful build, the skill asks which semantic version increment (major, minor, or patch) to apply to the parent POM version, and updates the child project to use it.

The skill doesn’t upgrade custom libraries that aren’t Anypoint Connectors, because it can’t verify their compatibility. Before it runs the upgrade, it lists these libraries and asks you to confirm that they work with the target versions.

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.

Custom Code in Connectors

If you have custom code in your connectors, or if you are using third-party libraries, you must update that custom code to be compatible with Java 17.

  • Reflection on Java classes

    To ensure compatibility with Java 17, review and update any code that uses reflection to access Java classes or set parameter values. Java 17 imposes stricter access controls, so avoid introspecting JDK internals. Have a robust test suite that runs with Java 17. Pay special attention to the setAccessible(true) method because these access changes are not allowed in Java 17.

  • Java Platform Module System (JPMS)

    JPMS was introduced in Java 9. This feature introduces stricter encapsulation, impacting how Mule modules interact with JDK classes. As Mule upgrades to Java 17 and JPMS, these changes are necessary:

    • Refactor Split Packages: Resolve issues with internal and API package splits by reorganizing and refactoring packages to conform with JPMS modularization standards.

    • Address ResourceBundle Loading: Implement solutions for issues related to resource bundle loading, such as using ResourceBundleProvider or alternative methods.

    • Analyze the third-party libraries' changelogs to understand Java 17 compatibility and changes related to JPMS.

  • Unsupported directives

    Don’t set --add-opens, --add-exports, or --add-modules directives. These directives are not allowed in CloudHub, Runtime Fabric, or on-premises. These directives also require managing them for each connector across all environments, and introduce a backward compatibility burden, complicating future Java upgrades and potentially enabling security vulnerabilities. If these directives are used, they are not covered under Support.

  • JDK Migration Guide

    See the Oracle JDK Migration Guide for a full list of the changes made from Java 8 to Java 17. Use the guide to assess the impact to your code.

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 Select a Different Java Version to Run the Embedded Mule Runtime and Update Mule Modules in Anypoint Studio.

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