Yes - managed server jars and the Java Integration step work the same way on containers (the jar is loaded by the process app's class loader inside the Liberty server). What changes is the environment the code runs in:
- Java level: the Liberty images use the IBM Semeru JDK of the release (Java 11 on 21.0.x/22.0.x, Java 17 on newer 24.0.x images) - jars compiled for Java 8 run, but check libraries that need javax.* packages removed in newer JDKs (JAXB, activation, annotation: add them to the jar).
- No WebSphere traditional APIs: com.ibm.websphere.* (work manager, security helpers, mail sessions by JNDI unless configured in Liberty), javax.ejb lookups, wsadmin calls - remove or replace.
- File system: the container's file system is ephemeral and read-only in places; write only to /tmp or to a persistent volume declared in the CR, or use object storage / ECM instead of files.
- Network egress goes through the cluster's egress / proxy; SFTP or SMTP hosts must be reachable from the pod network (NetworkPolicies, the cluster proxy settings).
- Threads and memory: the JVM shares the pod's limit with the engine; long-running Java work should not spawn thread pools of its own.
- Cryptography: FIPS-enabled clusters restrict algorithms; use the JDK providers, not bundled BouncyCastle with non-FIPS algorithms.
// safe file handling in a container: temp file under /tmp, then hand the bytes to the document store
java.nio.file.Path tmp = java.nio.file.Files.createTempFile("invoice-", ".pdf");
try { buildPdf(tmp); return java.util.Base64.getEncoder().encodeToString(java.nio.file.Files.readAllBytes(tmp)); }
finally { java.nio.file.Files.deleteIfExists(tmp); }Test each jar in a Liberty-based development namespace before migrating; the validation report of the imported snapshot does not detect runtime incompatibilities. Alternatives to Java for new work on containers: REST external services, App Connect flows, or an ADS decision service - all first-class in the Cloud Pak.
References