[
https://issues.apache.org/jira/browse/GEODE-10494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang reassigned GEODE-10494:
------------------------------------
Assignee: Jinwoo Hwang
> Removal of --add-exports JVM arguments for Java compatibility and
> future-proofing
> ---------------------------------------------------------------------------------
>
> Key: GEODE-10494
> URL: https://issues.apache.org/jira/browse/GEODE-10494
> Project: Geode
> Issue Type: Improvement
> Reporter: Jinwoo Hwang
> Assignee: Jinwoo Hwang
> Priority: Major
>
> ## Summary
> Remove all `--add-exports` JVM arguments from Geode build configuration to
> improve compatibility with future Java versions and follow best practices for
> module system usage.
> ## Description
> Geode currently uses multiple `--add-exports` JVM arguments to access
> internal JDK APIs. While this works for current Java versions, it creates
> several issues:
> 1. **Future Java Compatibility**: Internal APIs exposed via `--add-exports`
> may be removed or changed in future Java versions
> 2. **Security Concerns**: Bypassing module encapsulation reduces security
> guarantees
> 3. **Maintenance Overhead**: Requires ongoing maintenance as Java evolves
> 4. **Build Warnings**: Generates deprecation warnings in newer Java versions
> ## Current Usage
> The following `--add-exports` are currently used across the codebase:
> - `--add-exports java.base/sun.nio.ch=ALL-UNNAMED`
> - `--add-exports java.management/sun.management=ALL-UNNAMED`
> - `--add-exports java.base/jdk.internal.ref=ALL-UNNAMED`
> - `--add-exports java.base/sun.security.util=ALL-UNNAMED`
> - Additional exports in test configurations
> ## Acceptance Criteria
> - [ ] Identify all locations using `--add-exports` in build.gradle files
> - [ ] Research public API alternatives for each internal API usage
> - [ ] Replace internal API calls with public alternatives where possible
> - [ ] Remove unnecessary `--add-exports` arguments
> - [ ] Document any remaining usage with justification
> - [ ] Ensure all tests pass without `--add-exports`
> - [ ] Verify compatibility with Java 8, 11, 17, and 21
> ## Technical Approach
> 1. **Audit Phase**: Catalog all `--add-exports` usage and corresponding code
> 2. **Research Phase**: Find public API replacements for each internal API
> 3. **Implementation Phase**:
> - Replace internal API usage with public alternatives
> - Use reflection with proper exception handling where needed
> - Implement feature detection for Java version-specific behavior
> 4. **Testing Phase**: Comprehensive testing across supported Java versions
> ## Benefits
> - **Future-proof**: Reduces risk of breakage in future Java versions
> - **Standards Compliance**: Follows Java module system best practices
> - **Cleaner Build**: Eliminates build warnings and reduces complexity
> - **Better Security**: Maintains module encapsulation boundaries
> ## Risk Assessment
> - **Medium Risk**: Some internal APIs may not have direct public replacements
> - **Mitigation**: Implement gradual migration with fallback mechanisms
> - **Testing**: Extensive testing across all supported Java versions required
> ## Related Work
> - Consider this work alongside any Java version upgrade initiatives
> - Coordinate with performance team if internal APIs are used for optimization
> - Review Apache Geode community guidelines for Java compatibility
> ## Definition of Done
> - All `--add-exports` arguments removed or documented with clear justification
> - Public API alternatives implemented for all internal API usage
> - Full test suite passes on Java 8, 11, 17, and 21
> - Documentation updated with any compatibility notes
> - Code review completed by Java platform experts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
