Configure the JDK Version for Deploy
This guide is for administrators who install or upgrade Digital.ai Deploy. It describes which JDK versions Deploy supports and how to select between them on JVM-based (installer) and operator-based (Kubernetes) installations.
Deploy 26.3 runs on both JDK 21 and JDK 25. On JVM-based installations, a single distribution supports both JDKs, and the JDK-specific runtime parameters are controlled through the wrapper configuration file, XL_DEPLOY_SERVER_HOME/conf/xld-wrapper.conf.common, and not through separate binaries.
Run Deploy on JDK 21
By default, Deploy 26.3 is configured to run on JDK 21. No configuration changes are required. Install JDK 21 and make sure the Deploy server uses it, as described in Configure Deploy as a daemon or service.
Existing JDK 21 installations continue to function without modification after upgrading to Deploy 26.3.
Switch to JDK 25
JDK 25 removes the Java Security Manager, which earlier Deploy versions used to sandbox Deployfile script execution. To run Deploy on JDK 25, you must remove the Security Manager settings from the wrapper configuration file. For more information about what the sandbox restricted, see SecurityManager configuration.
To switch the Deploy server to JDK 25:
-
Install JDK 25 on the server and configure the Deploy server to use it, as described in Configure Deploy as a daemon or service.
-
Stop the Deploy server.
-
Open
XL_DEPLOY_SERVER_HOME/conf/xld-wrapper.conf.commonand remove the following lines:wrapper.java.additional.4=-Djava.security.manager=java.lang.SecurityManagerwrapper.java.additional.5=-Djava.security.policy=conf/xl-deploy.policyIf you have customized the wrapper configuration file, the index numbers may differ. Remove the
wrapper.java.additionalentries that set-Djava.security.managerand-Djava.security.policy. -
In the same file, locate the
wrapper.java.additionalentry for--sun-misc-unsafe-memory-access=allowand uncomment it. If the entry is not present, add it using the next availablewrapper.java.additionalindex. Do not assume that the index is13.This allows
sun.misc.Unsafememory access and suppresses the Pekko warnings that JDK 25 logs at startup. -
Start the Deploy server.
Select the JDK Version on Kubernetes
On operator-based (Kubernetes) installations, the JDK is determined by the container image, not by the wrapper configuration file. The default Deploy server image tags run on JDK 21. To run the Deploy server on JDK 25, use the image tag with the -jdk25 suffix.
Set the image tag in the custom resource (CR), the same fields you use for a patch upgrade:
kubectl patch -n digitalai digitalaideploys.xld.digital.ai dai-xld \
--type=merge --patch '{"spec": {"master": {"image": {"tag": "26.3.x-jdk25"}}}}'
kubectl patch -n digitalai digitalaideploys.xld.digital.ai dai-xld \
--type=merge --patch '{"spec": {"worker": {"image": {"tag": "26.3.x-jdk25"}}}}'
The operator restarts the Deploy pods automatically after the update. For more information about setting the image tag, see Upgrade Patch Version of the Deploy.
The -jdk25 image is preconfigured for JDK 25 and does not include the Java Security Manager settings, so you do not need to edit the wrapper configuration file. Deploy 26.3 does not sandbox Deployfile script execution on either JDK 21 or JDK 25. For more information about what the sandbox restricted, see SecurityManager configuration.
The xl-deploy.policy file
To support JDK 25, Deploy 26.3 no longer uses the Java Security Manager and does not read the conf/xl-deploy.policy file. Deploy 26.3 ignores this file when it runs on either JDK 21 or JDK 25.
After upgrading to Deploy 26.3, remove any existing XL_DEPLOY_SERVER_HOME/conf/xl-deploy.policy file from the Deploy installation.
Any permissions previously defined in this file are no longer enforced. The Java Security Manager-based sandboxing mechanism has been removed, and Deployfile scripts are no longer subject to restrictions defined in conf/xl-deploy.policy.
Before upgrading to Deploy 26.3 in production, review any Deployfile scripts that relied on the Security Manager sandbox and test them in a non-production environment. There is no drop-in replacement for the Java Security Manager.