Most release-note coverage is about new features. This post is about two dated items in Adobe’s current AEM as a Cloud Service release notes (page last updated October 27, 2026) that can’t be postponed: the Java 25 runtime timeline, and the enforcement of deprecated Java API removals. One of the key dates has already passed. We summarize what Adobe says, quote the important lines, point out where Adobe’s own pages disagree, and list what we’d check this week.
Status and Source Notes
| Item | What the documentation says |
| Java 25 timeline | PLANNED TIMELINE. Listed under “Preparing for Java 25” in the release notes’ Important Notices, which carry no feature status labels. Adobe’s page says: “Any updates to this timeline will be communicated via release notes.” The same milestones appear on the 2026.7.0 release notes, so the two pages are consistent on this one. |
| Deprecated Java API enforcement | NOT NEW. Enforcement has been in effect for months: Adobe says pipelines have been failing at the Code Quality step for affected code since April 14, 2026. What is recent is the date after which environments lose critical updates, which the current notes put at September 28, 2026 — ALREADY PASSED. |
| Where Adobe’s pages disagree | The 2026.7.0 release notes give the critical-updates cutoff as September 14, 2026, while the current notes say September 28, 2026. We treat the current notes (updated October 27) as the latest, but confirm with Adobe which date applies to your environments. |
Timeline Diagram
Deprecated-API enforcement (top) and the Java 25 timeline (bottom), per Adobe’s current release notes.
Part 1: The Java 25 Timeline
Adobe describes Java 25 as the next long-term support (LTS) release after Java 21. The milestones it lists:
| When | What Adobe says |
| Mid-October 2026 | “AEM Cloud Service SDK supports Java 25 runtime.” The Java 25 JDK is available for download from the Adobe Software Distribution portal. We did not verify that this has shipped; check the SDK before relying on it. |
| November 2026 | Customers are encouraged to optionally enable the Java 25 runtime in their Cloud environments to validate behavior, since early adoption maximizes time to surface and resolve issues. |
| February to May 2027 | Adobe gradually migrates lower environments (RDE, Dev) to Java 25. Customers should validate behavior and report unexpected issues, and are encouraged to enable staging and production as well. “A temporary rollback to Java 21 is available while resolving any problems.” |
| June 2027 | “All environment runtimes (including staging and production) migrate to Java 25.” “Java 21 runtime is decommissioned.” “The AEM Cloud Service SDK will no longer support Java 21.” |
Compiling your code is a separate question
“AEM Cloud Service continues to support compiling customer code with Java 11, Java 17, and Java 21.”
“However, Adobe recommends building with Java 25 (once available in AEM)”
So the runtime and the compile target are different decisions. Adobe’s wording is that existing compile targets continue to be supported, and that it recommends building with Java 25 once that is available in AEM.
What the notes we read don’t say
- How you opt in to the November enablement, or whether it is per program or per environment.
- How the February–May lower-environment migration is scheduled for an individual program.
- Whether the mid-October SDK milestone has already been delivered. We didn’t verify this.
Part 2: The Deprecated Java API Deadline
This is not a new feature; it is enforcement of removals Adobe has been signalling. The current notes say:
“It is critical to remove usage of deprecated APIs before September 28, 2026.”
“Since April 14, 2026, Cloud Manager pipelines that contain code using APIs targeting 2/26/2026 removal fail during the Code Quality step.” Deployments are blocked until the deprecated usage is removed.
“Starting September 28, 2026, environments still using these deprecated APIs will not receive critical Adobe release updates and will not be subject to Adobe’s standard commitments around performance and availability.”
Adobe adds that affected environments would not receive new features or bug fixes, that application stability and uptime may be negatively affected, and that security risk exposure may increase further.
The packages Adobe lists
The current notes name these 14 packages:
- org.apache.sling.commons.auth
- org.apache.felix.webconsole
- org.eclipse.jetty
- com.mongodb
- org.apache.abdera
- org.apache.felix.http.whiteboard
- org.apache.cocoon.xml
- ch.qos.logback
- org.slf4j.spi
- org.slf4j.event
- org.apache.log4j
- com.google.common
- com.drew
- org.apache.jackrabbit.oak.plugins.memory
How Adobe says to find usages
Per Adobe’s “Find and remove deprecated APIs” tutorial (last updated October 9, 2026):
- Tool: the AEM Analyser Maven Plugin. The tutorial describes adding it to the build of the project’s “all” module and binding its analysis goal to the verify phase. Check the tutorial for the current plugin version; we haven’t reproduced one.
- Use the latest SDK. The tutorial says the latest SDK API artifact lets the plugin surface deprecated APIs as IDE warnings.
- Reporting: warnings are reported per bundle, identified by Maven coordinates, with the rule ID region-deprecated-api and the deprecated package, grouped for author and publish.
- Where you’ll see results: the AEM as a Cloud Service Actions Center, the Cloud Manager Code Scanning step (in the Download Details report), and the Artifact Preparation step (build log, under “Analyser warnings”).
| Warning type | Adobe’s suggested remediation |
| Deprecated AEM API | Replace with the supported public API. |
| Deprecated AEM package or class | Refactor to the recommended alternative. |
| Deprecated third-party library | Upgrade the dependency and refactor usage. |
| Legacy Sling/OSGi patterns | Migrate to modern APIs. |
| Planned future removal | Schedule cleanup before enforcement. |
The tutorial’s practical advice is to treat warnings as future pipeline failures, fix them locally against the latest SDK, and keep the analyzer output clean. It does not state whether current pipeline runs fail on every analyzer warning; the release notes’ statement about the Code Quality step refers to code using APIs targeted for removal.
A note on Guava: com.google.common is on the list. Adobe’s cloud migration skill (covered in our earlier post) includes a pattern for Guava cache usage, which it describes as swapping to Caffeine. We haven’t seen Adobe state that this pattern covers all of com.google.common, so don’t assume it does.
What We’d Check This Week (Our Reading)
This section is our interpretation, not Adobe guidance, and we haven’t run this on a customer project.
- Start with the deprecated APIs, because the date has passed. Run the analyzer against the latest SDK and see whether any of the 14 packages appear. Remember to look at the dependencies you pull in, not only your own code.
- Ask Adobe which cutoff applies to you. Given the September 14 vs 28 discrepancy between its pages, confirm the status of your own environments.
- Put Java 25 on the roadmap now. June 2027 is the date Adobe lists for all runtimes, and the November window is optional but encouraged. Test your build tooling, CI images, IDEs, and third-party dependencies against Java 25 before the lower-environment migration starts.
- Don’t conflate compile target and runtime. Adobe says compiling with Java 11, 17, and 21 stays supported, but the runtime will move to 25.
- Use the rollback window deliberately. The temporary rollback to Java 21 is mentioned in connection with the February–May lower-environment migration; ask Adobe how long it lasts and how to request it.
What We Haven’t Verified
- We read Adobe’s pages on October 29, 2026. The current release notes were last updated October 27, 2026; the 2026.7.0 notes and the deprecation tutorial were last updated October 9, 2026.
- We read them through a summarizing tool that splits long quotes. We matched milestones to dates by position, and the 2026.7.0 page gave the same pairing independently, but please check the table against the live page.
- We did not verify that the Java 25 SDK support has shipped, how to opt in to November enablement, or the rollback mechanics.
- We did not run the analyzer against any project, and we did not verify which environments are or aren’t affected by the September cutoff.
- Adobe says timeline updates will be communicated via release notes. These dates may change.
This-Week Checklist
- Run the AEM Analyser Maven Plugin against the latest SDK and review every deprecated-API warning
- Check whether any of the 14 listed packages appear in your code or your dependencies
- Review the Cloud Manager Code Scanning and Artifact Preparation results, and the Actions Center
- Ask Adobe which critical-updates cutoff (September 14 or 28) applies to your environments
- Plan remediation by warning type, starting with deprecated third-party libraries
- Confirm the Java 25 SDK and JDK are available to you, then try your build on it
- Test CI images, IDEs, build plugins, and dependencies against Java 25
- Decide whether to opt in to the optional November enablement on a non-production environment
- Ask Adobe how the lower-environment migration and the Java 21 rollback work for your program
- Re-check the release notes for timeline changes before each milestone
Final Thoughts
New features get the attention, but dated runtime and API changes are the ones that can quietly put an environment on the wrong side of a support line. The sensible response is dull and effective: clean up the deprecated APIs now, put Java 25 testing on the calendar, and confirm the details that Adobe’s own pages leave inconsistent. Then keep an eye on the release notes, since Adobe says that is where timeline changes will appear.
