[
https://issues.apache.org/jira/browse/GEODE-10494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10494:
---------------------------------
Description:
*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
was:
## 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
> 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)
