Java 17, Jakarta EE 10, Spring 6—and a thousand dominoes

By: Jinwoo Hwang
Lead Developer, Project Lead, and Release Manager, Apache Geode 2.0
https://JinwooHwang.com

This post is divided into three parts. Part I explains why Apache Geode 2.0 matters. Part II walks through how it was modernized. Stay tuned for Part III which looks ahead—what we learned, what changed, and how you can help shape what comes next.

Modernizing Apache Geode 2.0 meant confronting decades of accumulated technical debt and a dense web of dependencies. This was not a linear upgrade path but a cascading transformation, in which each change triggered many more. What began as a security necessity quickly became a full‑scale re‑architecture.

The Reality of Scale

Apache Geode is not a small project. The codebase spans more than 11,000 Java classes, over 10,000 test cases, and 32 subprojects. Every decision rippled across build tooling, runtime compatibility, security, CLI tooling, web containers, and user‑facing APIs.

The Domino Effect of Dependencies

Modernization followed a strict dependency order:

• Gradle: Upgraded from 6 to 7 to support Java 17.
• Java: Migrated from JDK 8 to JDK 17 LTS.
• Jakarta EE: Full migration to Jakarta EE 10 and the jakarta.* namespace.
• Spring Framework: Upgraded to Spring Framework 6.
• Spring Security: Complete rewrite using modern security configuration models.

Ignoring this order led to compounding failures. Respecting it restored momentum.

Security as a First‑Class Driver

Security was not a side concern—it was a primary motivator. Apache Geode 2.0 remediates critical vulnerabilities, including deserialization flaws, SSRF risks, denial‑of‑service vectors, path traversal issues, and authentication weaknesses. Upgrading to supported frameworks restored the ability to receive timely security patches.

Major Platform Transformations

• CLI (GFSH): Fully rewritten using Spring Shell 3.x, modernizing over 118 commands.
• HTTP and REST: Migrated to Apache HttpComponents 5 with HTTP/2 support.
• Search: Upgraded to Apache Lucene 9 with updated command integration.
• Web Containers: Migrated to Eclipse Jetty 12 and Apache Tomcat 10.1+, embracing Jakarta EE 10.

One unavoidable breaking change was Tomcat session management. Legacy Tomcat versions (6–9) are no longer supported. Users must remain on Apache Geode 1.x or migrate to the new Tomcat 10 module.

By the end of the effort, more than 800 files were changed, over 18,000 lines added, and all 10,600+ tests passed cleanly. Apache Geode 2.0 now runs on a fully modern, supported, and maintainable foundation.

When the last dependency finally fell into place and the build turned green, the work was not finished. The most valuable outcomes of Apache Geode 2.0 were not only technical—they were the lessons learned and the foundation laid for the future.

Learn what Apache Geode is https://geode.apache.org/