Overview
A typical engagement starts with an engineering organization whose Java services run on JDK 8, 11, 17 and 21, built and deployed by many teams. Upgrades happen when a vendor or an audit forces them, and each one competes with feature work. The platform team wants a standing way to stay within a release or two of current.
Challenge
Java ships a feature release every six months and an LTS release every two years, and Oracle's roadmap lists the next planned LTS as Java 29 in September 2027. The documented breaks between releases are known: the Java EE modules removed in Java 11, strong encapsulation of JDK internals in Java 17 and the Security Manager disabled in Java 24. What is unknown is which services hit which break, and which library or agent blocks the most of them.
Environment
Several hundred services built with Maven and Gradle, packaged as container images on Kubernetes, with a mix of Spring Boot generations, bytecode agents for monitoring, a few application servers, and a CI system that builds each service on whichever JDK its team chose.
Approach
AceMQ engineers inventory the JDK release and build in every service, then run the dependency and deprecation scanners that ship with the JDK across the repositories and join the results to the build files. Blockers are ranked by the number of services each one stops. The team writes a currency policy, one reference base image per LTS, and a wave plan that starts with low-risk services. The engagement covers the runtime and its surroundings, not changes to application code.
Solution
- Inventory of services by JDK release, build, framework generation and memory settings
- Scan with jdeps and jdeprscan across repositories, joined to build files and ranked by services blocked
- Written currency policy: maximum gap from current, a named calendar owner and a recorded exception process
- Target release per service, with framework floors such as Spring Boot 3 and Kafka 4.0 brokers needing Java 17 taken into account
- One reference base image per LTS and a nightly CI job that builds a sample of services on the newest release
- Pilot wave on low-risk services with measured memory and start-up behaviour, and a rollback for each wave
Outcome
The engagement delivers the inventory, a ranked blocker list, the currency policy and calendar, reference images and CI checks, wave plans with rollbacks, and runbooks for the next release. The organization's own developers make any code changes the blockers require, and AceMQ can run the first waves alongside them. Licensing and distribution questions stay with the customer's agreements and counsel.
Technologies
JavaOpenJDK
Kubernetes
Docker
Prometheus
Kong
PostgreSQL
Redis
Kibana
