[
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. This effort is to remove the dependency at least during
Geode runtime.
*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)
