Skip to content

Java in AEM: Which Versions AEM Runs On and How to Set the Build JDK

Which Java AEM runs on: Java 21 on AEM as a Cloud Service and the Java 25 plan, Java 8/11 on AEM 6.5, 17/21 on 6.5 LTS; setting the Cloud Manager build JDK; the Java APIs to use.

Written in October 2026 and checked against Adobe's release notes, build environment documentation and technical requirements.

On this page
  1. Java versions by AEM product
  2. AEM as a Cloud Service: the runtime
  3. AEM as a Cloud Service: the build JDK
  4. AEM 6.5 and AEM 6.5 LTS
  5. The Java APIs you use in AEM
  6. Java APIs removed from AEM as a Cloud Service
  7. Java rules that Cloud Service code must follow
  8. Common questions

AEM is a Java application, and AEM development is mostly Java development: Sling Models, OSGi services, servlets and workflow steps. The question "which Java?" has three different answers, and mixing them up breaks builds:

  1. the runtime, the Java version AEM itself runs on;
  2. the build JDK, the Java version Cloud Manager or your machine compiles with;
  3. the bytecode target, the release level your Maven project compiles to.

Java versions by AEM product

ProductJava
AEM as a Cloud ServiceJava 21 runtime on every environment. Java 25 is planned.
AEM 6.5 LTSJava 17 and Java 21 (Oracle Java SE; IBM Semeru with WebSphere only)
AEM 6.5Java 8 and Java 11 (Oracle Java SE, or Azul Zulu OpenJDK from service pack 9). Java 17 and 21 aren't supported.

AEM as a Cloud Service: the runtime

Adobe chooses the runtime Java for each environment; you don't. The move to Java 21 went like this:

  • 18 September 2025: development environments and RDEs were moved to the Java 21 runtime.
  • 14 October 2025: stage and production environments followed.
  • February 2026: the Java 11 runtime stopped working in the SDK and in every cloud environment.

Java 25 is next. Adobe announced the plan in release 2026.8.0, and the current release notes give this schedule:

  • November 2026: customers can opt in to the Java 25 runtime for an environment, to test.
  • February to May 2027: Adobe moves RDEs and development environments to Java 25, with a temporary rollback to Java 21 possible.
  • June 2027: all environments run Java 25, and the Java 21 runtime is retired.

To check what an environment runs, look in the Developer Console, or log System.getProperty("java.version") from an OSGi component.

AEM as a Cloud Service: the build JDK

The Cloud Manager build image has JDK 11, 17 and 21 installed, but its default JAVA_HOME is still JDK 8. Choose the JDK yourself with a file in the branch the pipeline builds:

.cloudmanager/java-version

It contains a single line, 21 or 17. Adobe prefers 21. Other values are ignored, and 8 is no longer supported for Cloud Service projects. Older guides set the JDK with Maven toolchains; Adobe's current build documentation describes only this file.

The AEM Project Archetype doesn't create this file. Archetype 58, from September 2026, compiles to Java 11 (<release>11</release> in the parent pom.xml). Add the file when you generate a project. The current release notes say Cloud Service still supports compiling customer code with Java 11, 17 and 21. An end to Java 11 builds will be announced separately.

When moving a project to a newer Java

  • Use at least bnd-maven-plugin 6.4.0, maven-bundle-plugin 5.1.5 and aemanalyser-maven-plugin 1.6.16. Note that bnd-maven-plugin 7 and maven-bundle-plugin 6 cannot build for Java 11 or lower.
  • Libraries that read bytecode need recent versions: ASM 9.5 or later, Groovy 4.0.22 or later, Aries SPIFly 1.3.6 or later.
  • On a local SDK running Java 21, older start scripts fail on -XX:MaxPermSize. Remove the option, or use SDK 19149 or later.
  • Builds on Java 17 or 21 run SonarQube 9.9 in the code quality step.

AEM 6.5 and AEM 6.5 LTS

AEM 6.5 runs on Java 8 or 11, and that won't change: the last 6.5 service pack is planned for November 2026, and core support for 6.5 on premises ends on 28 February 2027. AEM 6.5 LTS, generally available since 7 March 2025, is the version to move to if you need Java 17 or 21. It runs on Jetty 11 and Oak 1.68, and it removed some old bundles, among them Guava. Internally it is versioned 6.6: the QuickStart is named cq-quickstart-6.6.x.jar and the current Uber Jar is 6.6.3. The product name is still AEM 6.5 LTS.

The Java APIs you use in AEM

Adobe's order of preference is AEM APIs first, then Sling, then JCR, then OSGi:

  • AEM APIs: PageManager, Page, Asset, DamUtil. Among them, prefer com.adobe.cq to com.adobe.granite, and use com.day.cq only when nothing newer exists.
  • Sling APIs: ResourceResolver, Resource, ValueMap, ModifiableValueMap, and Sling Models for component logic (see Sling Models vs WCMUsePojo).
  • JCR API (javax.jcr, JCR 2.0): Session, Node, JcrUtils, when the higher-level APIs are not enough.
  • OSGi: Declarative Services annotations for components and services, not the old Felix SCR annotations. Register servlets with @SlingServletResourceTypes rather than by path.

On AEM as a Cloud Service, these APIs come from one Maven dependency, com.adobe.aem:aem-sdk-api, in provided scope, with its version matching your AEM release. The Javadoc is published on Experience League. Not everything in the Javadoc is safe to use: it still lists deprecated packages, so check Adobe's removal list before you rely on one.

Service users, not admin sessions

loginAdministrative() and getAdministrativeResourceResolver() are deprecated because they give code far more access than it needs. Create a service user with repoinit, map it to your bundle with a ServiceUserMapperImpl.amended configuration, and open it with getServiceResourceResolver() in a try-with-resources block, so it is always closed.

Java APIs removed from AEM as a Cloud Service

Adobe is removing a number of old libraries from the Cloud Service runtime. Since 14 April 2026, pipelines fail at the code quality step when code still uses the first batch. Since 28 September 2026, environments that still use them no longer receive critical updates. Among them:

PackageUse instead
com.google.common.* (Guava)JDK collections, Commons Collections 4, or embed Guava in your own bundle
org.apache.log4j.* (Log4j 1)SLF4J
org.apache.sling.commons.authorg.apache.sling.auth.core
org.eclipse.jetty.*, com.mongodb.*Other libraries, or embed your own copy
org.apache.commons.lang (Commons Lang 2)org.apache.commons.lang3 (removal planned, tentatively, for the end of 2027)
org.json, org.apache.sling.commons.jsonApache Johnzon (javax.json) (removal planned, tentatively, for the end of 2027)

Adobe's "Deprecated and Removed Features" page has the full list with dates.

Java rules that Cloud Service code must follow

  • Code always runs on more than one node, and old and new code run side by side during a deployment. Keep no state in memory and nothing on the local file system.
  • Run background work as Sling Jobs, which run at least once. Adobe's code quality rules flag the Sling Commons Scheduler because its jobs are not guaranteed to run.
  • Set explicit timeouts on every outgoing HTTP call (Adobe suggests about 1 second to connect and 5 seconds to read) and reuse HttpClient instances. Without your own timeouts, AEM caps connections at 10 seconds to connect and 60 seconds to read.
  • Close every ResourceResolver you open, and don't hardcode /apps or /libs paths. Both are code quality rules.
  • No native binaries or JNI.

Common questions

Which Java does AEM as a Cloud Service use?

Java 21, on every environment since October 2025. Java 25 is planned to replace it by June 2027.

How do I tell Cloud Manager which JDK to build with?

Commit .cloudmanager/java-version containing 21 (or 17). Without it, the build uses the image's default JDK 8.

Can AEM 6.5 run on Java 17?

No. AEM 6.5 supports Java 8 and 11, nothing newer. Java 17 and 21 need AEM 6.5 LTS or AEM as a Cloud Service.

Which Java should I install for local development?

For the AEM as a Cloud Service SDK, Java 21, matching the cloud runtime. For AEM 6.5, Java 11.

Related: AEM as a Cloud Service, AEM architecture and modern AEM component implementation patterns.

More in Architecture and platform