Jinwoo Hwang created GEODE-10466:
------------------------------------
Summary: Migrate Apache Geode from Java EE to Jakarta EE
Key: GEODE-10466
URL: https://issues.apache.org/jira/browse/GEODE-10466
Project: Geode
Issue Type: Improvement
Reporter: Jinwoo Hwang
h3. Background
With the transition from Java EE to Jakarta EE (starting with Jakarta EE 9),
the namespace for enterprise Java APIs changed from {{javax.*}} to
{{{}jakarta.*{}}}. This migration is necessary to:
* Maintain compatibility with modern application servers (Tomcat 10+, Jetty
11+, etc.)
* Support latest Spring Framework versions (6.0+)
* Ensure long-term sustainability and vendor support
* Align with industry standards and best practices
h3. Current State
Apache Geode currently uses {{javax.*}} packages in several modules, primarily:
* *Servlet APIs* in web-related modules
* *Annotation APIs* for dependency injection and validation
* *HTTP session management* components
* *REST API endpoints* and web controllers
h3. Scope of Work
h4. Affected Modules
*
[geode-web|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
- Core web functionality and servlet integration
*
[geode-web-api|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
- REST API interfaces and controllers
*
[geode-web-management|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
- Management REST endpoints
*
[geode-core|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
- Limited javax usage (primarily annotations)
*
[geode-assembly|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
- Web container integration and packaging
h4. Key Changes Required
# *Dependency Updates*
** Replace {{javax.servlet:javax.servlet-api}} with
{{jakarta.servlet:jakarta.servlet-api}}
** Replace {{javax.annotation:javax.annotation-api}} with
{{jakarta.annotation:jakarta.annotation-api}}
** Update Spring Framework to Jakarta EE compatible versions (6.0+)
# *Package Name Migration*
// Before
import javax.servlet.http.HttpServletRequest;
import javax.annotation.PostConstruct;
// After
import jakarta.servlet.http.HttpServletRequest;
import jakarta.annotation.PostConstruct;
# *Build Configuration Updates*
** Update Gradle dependencies in affected modules
** Ensure compatibility with Jakarta EE 9+ specifications
** Update version constraints and BOM files
h3. Acceptance Criteria
h4. Functional Requirements
* All {{javax.*}} imports replaced with corresponding {{jakarta.*}} imports
* All build dependencies updated to Jakarta EE compatible versions
* REST API endpoints function identically to current implementation
* Web management interfaces remain fully operational
* HTTP session management continues to work as expected
h4. Technical Requirements
* All unit tests pass without modification
* Integration tests pass
* No performance regression compared to current implementation
* Backward compatibility maintained where possible
* CI/CD pipeline updated to test against Jakarta EE environments
h3. Implementation Plan
h4. Phase 1: Assessment and Preparation (1-2 weeks)
* Complete comprehensive audit of all {{javax.*}} usage
* Identify third-party dependencies requiring updates
* Create automated migration scripts for package name changes
* Set up test environments with Jakarta EE compatible containers
h4. Phase 2: Core Migration (2-3 weeks)
* Update build dependencies and version constraints
* Execute automated package name migration
* Update web module implementations
* Resolve compilation and runtime issues
h4. Phase 3: Testing and Validation (2 weeks)
* Execute full test suite against Jakarta EE environment
* Perform integration testing with supported application servers
* Validate REST API functionality and performance
* Test web management interface compatibility
h4. Phase 4: Documentation and Release (1 week)
* Update user documentation and migration guides
* Create compatibility matrix for supported containers
* Update examples and sample applications
* Prepare release notes with breaking changes
h3. Risks and Mitigation
h4. Technical Risks
* {*}Third-party library compatibility{*}: Some dependencies may not support
Jakarta EE
** {_}Mitigation{_}: Identify alternatives or request vendor updates early
* {*}Application server compatibility{*}: Older containers may not support
Jakarta EE
** {_}Mitigation{_}: Document minimum supported versions clearly
* {*}Performance impact{*}: Package changes may affect performance
** {_}Mitigation{_}: Comprehensive performance testing and benchmarking
h4. Project Risks
* {*}Breaking changes for users{*}: Applications using Geode web features may
require updates
** {_}Mitigation{_}: Provide detailed migration guide and deprecation notices
* {*}Timeline dependencies{*}: Spring Framework and other dependencies must be
updated first
** {_}Mitigation{_}: Coordinate with dependency update schedules
h3. Success Metrics
* 100% of {{javax.*}} references migrated to {{jakarta.*}}
* All existing functionality preserved
* CI/CD pipeline fully operational with Jakarta EE
* Zero performance regression
* Complete documentation coverage
h3. Additional Notes
This migration aligns Apache Geode with modern Java enterprise standards and
ensures long-term compatibility with evolving Java ecosystem. The work should
be coordinated with any planned Spring Framework upgrades and application
server certification updates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
