Jinwoo Hwang created GEODE-10494:
------------------------------------
Summary: 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
## 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)
