"AEM 6.6" and AEM on Java 17 - What We Know & How to Prepare

A new version of AEM is on the way shortly from Adobe! When AEM as a Cloud Service first launched in 2020, all of us (and every Adobe Engineering individual I’ve talked to) was convinced that AEM 6.5 would be the last on-premise or self-hosted AEM version.

Updated 13 Nov 2024

But times are changing! A talk at this year's adaptTo() conference gave details on what is coming and what to expect for all AEM on-premise, self-hosted and AMS customers. We give an overview of the important points at the 11-minute mark of our adaptTo() recap here:

Details we have from that adaptTo() talk (as well as other details I've been able to gather from other sources) are as follows:

A New Version of AEM 6.x is on the Way

There will indeed be a new version of Adobe Experience Manager 6.x released for on-premise, self-hosted and Adobe AEM Managed Services (AMS) customers. The key driver for this new version is to update AEM to work on Java 17.

The naming for this version of AEM (at this writing) not yet final, so the code name that Adobe has officially given so far for it is "AEM 6.5 2025 Edition".

I hope with all of my soul that Adobe will have a different final name for this, as "6.5 2025 Edition" will create potentially destructive confusion. AEM versions are named with "[major version].[service pack version].[hotfix version]. We are currently on 6.5.21.0, with Service Pack 22 coming out shortly and a new service pack being released every quarter. This means, we'll soon have 6.5.2025 and 6.5.25.0 sitting right next to each other, and goodness I hope that doesn't happen. Please, let's just have 6.6, it will be easier.

The adaptTo() 2024 Talk on AEM 6.x and JDK 17

AEM 6.x Running on JDK 17

The impetus for creating a new version of AEM was to be able to move AEM off of JDK 8 and JDK 11, and onto a more-modern Java version, so as to be able to solve for upstream security vulnerabilities that won't be patched in JDK 11 or JDK 8.

This has entailed a far-reaching engineering effort to refresh the Apache Oak, Java Content Repository, Sling core which comprises the "engine" of AEM, as well as other APIs and components to be able to run with JDK 17. The effort also includes being able to maintain the latest 6.5 Service Pack feature set (which has offered considerable new features since the original 6.5.0 release), as well as allowing for a long-term support strategy for customers who aim to continue to run AEM on-premise or on AMS for the conceivable future.

There will be some deprecated APIs and features that can’t make it to AEM 6.6 (which is what I'm going to call it until someone tells me very sternly not to), and as such there will be a preparation and migration project for anyone who is still on 6.5 when this comes out.

Support for WAR and JAR Deployment Models

Indicative of the far-reaching nature of Adobe's AEM 6.5 installed-base is the fact that the AEM engineering team will be releasing this new version of AEM with support for both a WAR or a JAR deployment model. This

This means that one can deploy it with a usual Felix/Jetty Quickstart deployment, or deploy it as a WAR inside of Tomcat or Websphere.

Deprecations in "AEM 6.5 2025 Edition"

As a result of the upgrade, the security issues the team was working to patch (and impending security issues) there will be a few different deprecations when this is deployed.

The major ones brought up were:

• commons-collections-3.x APIs are deprecated
• the Guava library was removed from the distribution (though you can still include the current version with your own product if you need it
• Other various 3rd-party libraries were updated.

From a packaging standpoint, the AEM Uberjar will be changing, there will be one uberjar for 6.5.2025 and one for deprecated. If you use deprecated APIs you have to include both.

What the Upgrade to 6.6 Looks Like for Existing 6.5 Sites

The upgrade process for 6.5 -> "6.6" or "6.5 2025 Edition" will be somewhat similar to what a 6.4 -> 6.5 upgrade project looked like. Two different upgrade mechanisms will be supported:

• In-Place Upgrade: upgrade to the new version in-place
• "Side-Grade" Using oak-upgrade: This would be a process similar to the oak-upgrade (also known as crx2oak) process that we used for 6.4 -> 6.5 upgrades.

The essential process will be:

1. Run the updated Pattern Detector tool which will be provided by Adobe, to scan your current AEM installation and point out elements which should be addressed prior to moving to the new version.
2. Follow the Pattern Detector guidelines: Execute a project to analyze the output from the Pattern Detector, work out the items that do indeed need to be fixed, and ameliorate such.
3. Execute upgrade steps: Execute either the in-place upgrade or side-grade, depending on your installation, needs, repository size, hardware, etc.
4. Deploy recompiled code: Your code will need to be recompiled on JDK 17, and issues will almost certainly arise when attempting to get this to compile, deploy and function.
5. QA & go-live

AEM as a Cloud Service Will Move to JDK 21

AEM Cloud Service (which currently runs on Java 11) will be moving to a JDK 21 runtime. We don't have a timeline on this, at this time, as this development process is still in-progress.

Obviously much work will be done by Adobe to minimize the impact of this upgrade, but depending on your situation there may be a small or medium-size engineering project to think with in Q1 or early Q2 of 2025 to upgrade your development pipeline, Cloud Manager builds and codebase to run on JDK21.

We will update this page as more details come forth! Please contact us if you have any questions on how these coming changes impact your Adobe Experience Cloud stack plans for 2025 and into the future, we'd be happy to share what we know.

Like what you heard? Have questions about what’s right for you? We’d love to talk! Contact Us

Podcast Episodes & Blog Posts