--- schema_version: "1" id: 3e34f6cca6b816361349536dcce146310ed3a3fbf23b83ca49ca45e7435f0356 title: Java Support collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/java-support.md canonical_url: https://docs.mulesoft.com/general/java-support source_site: docs.mulesoft.com content_type: documentation content_hash: b6e1513bce31ecae4de1f3b26a84f8af17280915634c868dc9027f572ebb0030 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started keywords: java support, mule runtime, java upgrade, mule apps, java version, mulesoft java compatibility --- # Java Support > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 VersionJava 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](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence). ## 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](#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](#mule-runtime). 2. Upgrade all [Anypoint Connectors and modules](#anypoint-connectors-and-modules), and [custom connectors](#custom-connectors) used within Mule apps and policies to Java 17. Connectors containing [custom Java code](#custom-code-in-connectors) need additional modifications to ensure compatibility with Java 17. 3. Upgrade your [policies](#policies). Policies containing custom Java code need additional modifications to ensure compatibility with Java 17. 4. Upgrade your [API proxies](#api-proxies) and [Mule apps](#mule-apps). Proxies containing custom Java code need additional modifications to ensure compatibility with Java 17. 5. Upgrade [Anypoint Studio](#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](#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](#mule-maven-plugin) 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](https://docs.mulesoft.com/release-notes/mule-runtime/updating-mule-4-versions). 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](https://docs.mulesoft.com/mule-runtime/latest/deploying) 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. > [!NOTE] 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. > [!IMPORTANT] 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](#memory-management) - [Default TLS Cipher Selection](#default-tls-cipher-selection) ### 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](https://help.salesforce.com/s/articleView?id=005132434&type=1). > [!NOTE] To ensure optimal operation of your apps and effectively leverage the Java 17 > improvements, you must conduct > [performance testing](https://docs.mulesoft.com/mule-runtime/latest/tuning-test-validations) and > [monitoring](https://docs.mulesoft.com/mule-runtime/latest/tuning-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)](https://bugs.openjdk.org/browse/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](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#optional-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](https://docs.mulesoft.com/release-notes/connector/anypoint-connector-release-notes#mule_4) 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](https://docs.mulesoft.com/exchange/asset-versions) 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](/mulesoft/current/en-us/general/_images/exchange-version-detail.png) For a list of Java 17-compatible connectors and their respective versions, see [Java 17-Compatible Anypoint Connectors](https://help.salesforce.com/s/articleView?id=000782248&type=1). ### 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](https://docs.mulesoft.com/studio/change-jdk-config-in-projects) 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](https://docs.mulesoft.com/mule-runtime/latest/deploying) 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 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: - [Mule SDK](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST SDK (beta)](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-rest-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-rest-connect-connectors) - [Configuration Properties Providers](https://docs.mulesoft.com/general/partner-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. Test your connector using [Module Testing Framework (beta)](https://docs.mulesoft.com/general/partner-connector-upgrade#test-your-custom-connector-with-mtf). 3. [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) 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: - [Mule SDK](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-rest-connect-connectors) - [Configuration Properties Providers](https://docs.mulesoft.com/general/customer-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. Test your connector using [MUnit](https://docs.mulesoft.com/general/customer-connector-upgrade#test-your-custom-connector-with-munit). 3. [Deploy your applications](https://docs.mulesoft.com/mule-runtime/latest/deploying) 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](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A) 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](https://docs.mulesoft.com/studio/change-jdk-config-in-projects) and [Update Mule Modules in Anypoint Studio](https://docs.mulesoft.com/studio/update-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. > [!IMPORTANT] 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](https://docs.mulesoft.com/general/upgrade-policies-proxies#upgrading-automated-policies) and [Upgrading API-Level Policies](https://docs.mulesoft.com/general/upgrade-policies-proxies#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. > [!IMPORTANT] 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](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4). - 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](https://docs.mulesoft.com/general/upgrade-policies-proxies#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: - [Deploy Applications to CloudHub Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub) - [Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub-2) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) ## 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: - [Java Format](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#java-support) - [Predefined Variables](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) ## See Also - [Connector Release Notes](https://docs.mulesoft.com/release-notes/connector/anypoint-connector-release-notes) - [Upgrading MuleSoft to Java 17: A Comprehensive Guide](https://help.salesforce.com/s/articleView?id=002139151&type=1)