AEM On-Premise with Java 17 or later

you can try on a latest archetype and change the java version in parent pom..i am just guessing ..may be you can give a try .. and also try on a latest aem service pack ..let me know the results ..

Meanwhile they seem to work on a version that will Support Oracle JDK 17...!

https://experienceleague.adobe.com/docs/experience-manager-65/deploying/introduction/technical-requirements.html?lang=en#java-virtual-machines

That's a great question, though I'm answering an old question (from a deleted-account), but the question is very relevant even today (2025), and it's a concern many of us share as well when thinking about the long-term maintenance of our on-premise instances. 

AEM is a Curated Product Stack, Not Just a Java App

AEM's foundation is in Java's dependencies. AEM is not a simple Java application, but rather as a pre-compiled and certified product stack. For 6.5 version, Adobe bundled very specific versions of key frameworks like Apache Sling and Apache Jackrabbit Oak.

AEM itself does not directly use Java in the sense of being tied to a single language runtime; it is built on top of Apache Sling and the OSGi framework, which in turn rely on the underlying JVM. So, whether a given Java version is supported really comes down to what versions of Sling, Oak, and other underlying libraries AEM is bundled with.

For AEM 6.5 specifically, Adobe has certified it for Java 11, and that remains the officially supported runtime. Moving to Java 17 or later is not just a drop-in replacement. Adobe would need to ensure that the Sling version used in AEM 6.5, along with Oak and other dependent bundles, are compatible with the JVM changes introduced after Java 11. For example:

• Sling Compatibility: Sling releases are tested against specific Java versions; a higher JVM may break classloading, reflection, or module access patterns.

• OSGi Framework: Java 17 introduces stricter encapsulation with the module system, which can impact OSGi classloading unless explicitly addressed.

• Third-party Libraries: AEM packages many embedded libraries (e.g., Lucene, Jackrabbit Oak) that must be validated against newer JVMs.

That’s why Java version upgrades usually come as part of an AEM Service Pack, Cumulative Fix Pack, or a major release, not something you can safely switch independently. Adobe’s official support matrix is the final word here—using an unsupported JVM may run in a dev environment, but it is not certified for production, which could create issues with Adobe Support.

Adobe does provide info on what versions are supported for teams to plan accordingly.

https://experienceleague.adobe.com/en/docs/experience-manager-65/content/implementing/deploying/introduction/technical-requirements#java-virtual-machines