Upgrading Java for Custom Connectors (Customers)

This guide applies to MuleSoft customers only. If you are a MuleSoft partner, see Upgrading Java for Custom Connectors (Partners).

Upgrade, test, and release your custom connectors for Java 17 to ensure compatibility within the MuleSoft ecosystem.

Before You Begin

Before upgrading and testing your custom connector for Java 17, you must be familiar with the following considerations:

Target compilation level

Ensure your custom connector runs with Java 17, but always use Java 8 as the target compilation level.

Because you must compile your custom connector with Java 8, use the Java compiler configuration from the Java SDK parent POM. You can’t use language features from Java 11 or Java 17.
Unsupported directives

Do not set -add-opens or -add-export directives.
Minimum Mule version

If your custom connector is running on Mule 4.5.x or earlier, you can’t run Java 17 tests that extend the MuleArtifactFunctionalTestCase, but you can still run Java 8 tests.

To decouple the minimum Mule version when running tests, add the -Dmunit.jvm parameter to use Java 17 as described in Test Your Custom Connector with MUnit.

Upgrade Your Custom Mule SDK Connectors

Upgrade your custom Mule SDK (Java SDK and XML SDK) connectors to Java 17.

Upgrade Third-Party Libraries

Upgrade the third-party libraries of your custom connector to be compatible with Java 17:

Java EE libraries

Mule 4.6.x exposes Java EE libraries differently than earlier Mule versions. You must add the BOM dependency to your custom connector and, if applicable, exclude the provided conflicting library. You can also add the libraries in the BOM dependency separately.

<muleJavaEeBomVersion>4.6.0</muleJavaEeBomVersion>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.mule</groupId>
        <artifactId>mule-javaee-runtime-bom</artifactId>
        <version>${muleJavaEeBomVersion}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

For more information, see Java EE Libraries.

External libraries

Upgrade external libraries, which are third-party libraries that are not bundled with your custom connector. Some examples include a JDBC driver, JMS broker client, or Groovy runtime. The following example shows a JDBC driver external library configuration:
```
@ExternalLib(name = "MySQL JDBC Driver",
description = "A JDBC driver that supports connection to the MySQL Database",
nameRegexpMatcher = "(.*)\\.jar",
requiredClassName = "com.mysql.jdbc.Driver",
coordinates = "mysql:mysql-connector-java:5.1.44")
public class MySqlConnectionProvider implements ConnectionProvider<Connection> {
  //
}
```
You must update your external libraries to a version that is compatible with Java 17.

Review Your Code

After you compile your custom connector with Java 8, ensure you can run your custom connector with Java 17. Reviewing your code is important because some restrictions are flagged as warnings in Java 11 but are flagged as failures and can’t be disabled in Java 17. For example, reflection is more restricted in Java 17, so you must review your code to ensure there are no illegal actions.

To help you review your code, learn more about the different changes in Java 17:

JDK Migration Guide

See the Oracle JDK Migration Guide for a full list of the changes made in Java 17. Use the guide to assess the impact to your code.
Mule runtime engine

See Mule Runtime to learn more about the Java 17 changes made in Mule runtime engine.
- Reflection on Java classes
- Serialization
- Library upgrades
- Changes with running the test suite
- JPMS

Add Missing Code

Because reflection is more restricted in Java 17, API objects now require setters. Previously, API objects and plain old Java objects (POJOs) had default constructors and getters for all properties. Now, API objects and 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, 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 simplify the validation and certification process.

Upgrade Your Custom REST Connect Connectors

Upgrade your custom REST Connect connectors to Java 17.

REST Connect now supports Java 17. REST Connect connectors are generated from an API specification using REST Connect. To make the connector Java 17-compatible, republish the API specification to Exchange. See REST Connect Connector Generator.

REST Connect now adds support for TLS. To save time, enable TLS at the same time you update your generated connector for Java 17 so that you need to generate the connector and test your apps only once.

Test Your Custom Connector with MUnit

Run your MUnit tests to test compatibility of your connector against Java 17. Ensure your local JDK version is 17.

Open the pom.xml file of your Mule app.
Replace the mule-maven-plugin version with the ${mule.maven.plugin.version} parameter.

If you haven’t already, add the munit-maven-plugin. Replace the version with the ${munit.version} parameter and replace runtimeVersion with the ${app.runtime} parameter.

	<plugin>
		<groupId>com.mulesoft.munit.tools</groupId>
		<artifactId>munit-maven-plugin</artifactId>
		<version>${munit.version}</version>
		<executions>
			<execution>
				<id>test</id>
				<phase>test</phase>
				<goals>
					<goal>test</goal>
					<goal>coverage-report</goal>
				</goals>
			</execution>
		</executions>
		<configuration>
			<coverage>
				<runCoverage>true</runCoverage>
				<formats>
					<format>html</format>
				</formats>
			</coverage>
			<runtimeVersion>${app.runtime}</runtimeVersion>
			<dynamicPorts>
				<dynamicPort>http.port</dynamicPort>
			</dynamicPorts>
		</configuration>
	</plugin>

MUnit 3.1 is compatible only with Mule runtime 4.3.0 and later. If your connector is compatible with Mule runtime 4.2.0 and earlier, you must create a legacy profile that overrides the MUnit version.

If you have MUnit dependencies, such as munit-runner and munit-tools, replace the version for each dependency with the ${munit-version} parameter.
Replace the version for each connector dependency with the Java 17 compatible version of the connector.

Open a terminal window in the root of your Mule project and run the following command:

mvn -f pom.xml -s ~/.m2/settings.xml -Dapp.runtime=4.6.0 -Dmunit.version=3.1.0 -Dmule.maven.plugin.version=4.1.0 -fae test

You can now see if your connector is compatible with Java 17. For more information about running MUnit tests, refer to MUnit.

The Mule runtime version you use determines the version of the mule-modules-parent. For example, if you use Mule runtime 4.6.0, you must use mule-modules-parent 1.6.0. Minor versions maintain a correspondence, such as Mule runtime 4.1.0 with mule-modules parent 1.1.0, Mule runtime 4.2.0 with mule-modules-parent 1.2.0, and so forth.

Java 17 is supported with Mule runtime 4.6.0 and later. However, a connector can be compatible with both Mule 4.3.0 and Java 17 simultaneously. If your connector must be compatible with Mule 4.3.0, its mule-modules-parent version cannot exceed 1.3.0. You do not necessarily need to use mule-modules-parent 1.6.0 for your connector to be compatible with Java 17. Using mule-modules-parent 1.6.0 is specifically required to leverage other features from the Mule runtime 4.6.0 in the connector.

Release Your Custom Connector

After you update your code and your tests are green, you are ready to release a new Java 17-compatible version of your custom connector.

To communicate Java 17 compatibility, generate metadata for Java compatibility of your custom connector by adding or upgrading the custom connector mule-sdk-api dependency to the latest version:
```
<dependency>
   <groupId>org.mule.sdk</groupId>
   <artifactId>mule-sdk-api</artifactId>
   <version>0.7.0</version>
</dependency>
```
For Java SDK, add the @JavaVersionSupport annotation in the same class as the @Extension annotation and include the JAVA_17 value, for example:

You don’t need to add any annotations for XML SDK because XML SDK modules are Java 17 compatible and inherit the property automatically.
```
@Extension(name = "Database")
@Operations(...)
@JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17})
public class DatabaseConnector {
..
}
```

In Mule 4.5.0 and later, custom connectors that do not specify the @JavaVersionSupport annotation are assumed to be compatible with Java 8 and Java 11.

You can mark your custom connector as compatible with Java 17 only; however, you must ensure that no adoption or backward compatibility issues exist.

When you deploy a Mule app, Mule verifies that all modules in the Mule app are compatible with the Java version. If Mule finds an incompatibility, Mule throws an error and the application does not deploy.

If you receive an error message specific to an XML SDK based connector, such as Extension 'module-error-handler-plugin' does not support Java 17. Supported versions are: [1.8, 11], this means that your Mule app still contains some connectors that are not compatible with Java 17. To resolve this error, upgrade all connectors in your Mule app to be compatible with Java 17.

If your code is compatible with Java 17 but you do not declare Java 17 compatibility, you can still get a successful test run.

To run a quick check on your custom connector or if all dependencies are not ready, pass the following argument to skip hard checks on the Java support declaration:

-M-Dmule.jvm.version.extension.enforcement=LOOSE

For more information, see Java Version Support.

Gartner names MuleSoft a Leader

Unleash the power of Salesforce Customer 360 through integration

Anypoint Platform Fundamentals

MuleSoft at World Tour