Setting up compatible Java versions to run Jobs or Microservices
Configure your Remote Engine to execute Jobs or Microservices using the appropriate Java version based on those artifacts' Java compatibility levels.
By default, a Remote Engine uses the Java version of its environment to execute Jobs or Microservices. With Remote Engine v2.13 and onwards, Java 17 is mandatory for engine startup.
- Recommended for engines starting from v2.13.9 (released in R2025-01): from that release, Remote Engine adopts a dynamic JVM selection mode. This mode automatically adapts the engine to the correct Java version to run Jobs or Microservices. See Adaptive mode: Configuring Remote Engine to dynamically select Java version.
- If your engine is v2.13 or later but still older than v2.13.9 and you cannot upgrade it to the latest version, following this procedure to specify the Java version to be used for executions. This approach is not dynamic and only one version can be specified. See Specifying a Java version to run Jobs or Microservices.
Adaptive mode: Configuring Remote Engine to dynamically select Java version
In this mode, Remote Engine automatically selects the appropriate Java instance based on the Java compatibility level of artifact to be executed (Jobs or Microservices).
This dynamic Java version (adaptive) mode helps you execute artifacts from different Studio versions without rebuilding.
- For further information about setting this level, see Setting compiler compliance level.
- For information about how the compatible Java versions evolve along with Studio versions, see Compatible Java environments.
Procedure
Typical use cases for the engine adaptive mode
- Jobs built to run on Java 8:
These Jobs are compiled with the Java 8 compliance level and does not include --add-opens (the Enable Java 17 compatibility checkbox is not selected). They are generally compatible with Java 11. Setting both Java 8 and 11 or setting Java 11 alone in adaptive mode ensures they run correctly.
Information noteTip: Java 8 does not support --add-opens. - Standard (data integration) Jobs built to run on Java
11:
These Jobs are compiled with the Java 8 compliance level and include --add-opens where needed (the Enable Java 17 compatibility checkbox is selected).
They are generally compatible with Java 11. Running them on Java 17 are possible but can be error-prone, as --add-opens may lack necessary modules for Java 17 to correctly work.
Setting Java 11 in adaptive mode allows it to handle these Jobs.
- Jobs built to run on Java 17:
These Jobs are compiled with the Java 17 compliance level. They run on the Java 17 instance set in adaptive mode or, if unset, on the engine’s default Java instance.
Specifying a Java version to run Jobs or Microservices
Configure your Remote Engine to run Jobs or Microservices using a specific Java version. If you have activated the adaptive mode explained above, ignore this section.
This section provides an alternative to the adaptive mode if the latter is not available to your engine version. It allows you to run the artifacts designed with Java versions older than Java 17.
When developing new Jobs or Microservices, consider building them with the add-opens option to ensure compatibility with Java 17. This option opens the necessary packages for Java 17 compatibility, making your Jobs or Microservices directly runnable on the newer Remote Engine version, without having to go through the procedure explained in this section for defining a specific Java version. For further information about how to use this add-opens option and its limitation, see Setting up Java in Talend Studio.
Procedure
Displaying Java versions used by a Remote Engine to run tasks
Before you begin
Procedure
- Go to the Engines tab of the Processing page.
- Click the engine name to display its details panel.
- Click the Configuration tab.
Results
