[
https://issues.apache.org/jira/browse/GEODE-10494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10494:
---------------------------------
Fix Version/s: 2.1.0
> 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
> Fix For: 2.1.0
>
>
> *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 17
> - Documentation updated with any compatibility notes
> - Code review completed by Java platform experts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
