[
https://issues.apache.org/jira/browse/GEODE-10522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10522:
---------------------------------
Description:
h2. Summary
Apache Geode currently requires the JVM flag
{{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}} to
collect VM statistics through the {{VMStats50}} class. This flag violates Java
Platform Module System (JPMS) encapsulation and should be eliminated to achieve
full module compliance.
h2. Problem Description
h3. Current State
The {{VMStats50}} class in {{geode-core}} uses reflection to access platform
MXBean methods for collecting VM statistics:
* File:
{{geode-core/src/main/java/org/apache/geode/internal/stats50/VMStats50.java}}
* Lines 155-185: Static initializer using reflection with
{{ClassPathLoader.forName()}}
* Line 172: Critical call to {{Method.setAccessible(true)}} on
{{getProcessCpuTime()}} method
* Lines 643-688: Runtime invocation using {{Method.invoke()}}
h3. Required JVM Flag
{code:java}
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
{code}
This flag is defined in {{MemberJvmOptions.java}} and is required for:
* All Geode server members
* All Geode locator members
* Embedded Geode instances (including those running in Tomcat containers)
* GFSH operations
h3. Technical Root Cause
The {{VMStats50}} class attempts to access the following platform MXBean
methods via reflection:
|Method|Purpose|Platform|
|{{getProcessCpuTime()}}|Process CPU time in nanoseconds|All platforms|
|{{getMaxFileDescriptorCount()}}|Maximum file descriptor limit|Unix-like only|
|{{getOpenFileDescriptorCount()}}|Currently open file descriptors|Unix-like
only|
The use of {{Method.setAccessible(true)}} on methods from the
{{jdk.management}} module requires the {{--add-opens}} flag to bypass strong
encapsulation introduced in Java 9+ (JEP 260, 261, 403).
h3. Why This Is a Problem
h4. 1. Security Violations
* {*}Module Encapsulation Breach{*}: The {{--add-opens}} flag explicitly
breaks Java's module system strong encapsulation, allowing reflection access to
internal implementation details
* {*}Attack Surface Expansion{*}: Opens the entire
{{com.sun.management.internal}} package to ALL-UNNAMED modules, not just Geode
code
* {*}Security Audit Failures{*}: Enterprise security scanners flag
{{--add-opens}} as a security risk requiring justification and exception
approval
* {*}Compliance Issues{*}: Violates security best practices in regulated
environments (financial services, healthcare, government)
h4. 2. Deployment Restrictions
* {*}Containerized Environments{*}: Some container platforms (Kubernetes,
Cloud Foundry) restrict or prohibit module-opening flags
* {*}Serverless Platforms{*}: AWS Lambda, Azure Functions, Google Cloud Run
may block JVM flags that weaken security boundaries
* {*}Corporate Security Policies{*}: Many enterprises have policies against
weakening module encapsulation
* {*}Cloud Platforms{*}: Azure, AWS, GCP security baselines may flag or reject
deployments with {{--add-opens}} flags
h4. 3. Operational Complexity
* {*}Configuration Burden{*}: Every Geode deployment requires manual JVM flag
configuration
* {*}Documentation Overhead{*}: Operators must understand why the flag is
needed and its security implications
* {*}Version Fragility{*}: Flag requirements may change across Java versions,
requiring deployment updates
* {*}Troubleshooting Difficulty{*}: Missing flag causes runtime failures that
may not be immediately obvious
h4. 4. Future Java Compatibility Risk
* {*}JEP 403 Trajectory{*}: Future Java versions may further restrict or
eliminate {{--add-opens}} capability
* {*}Deprecation Risk{*}: Reflection access to internal APIs is increasingly
discouraged by the OpenJDK project
* {*}Migration Burden{*}: Delaying resolution increases future migration
complexity and risk
h3. Impact Scope
h4. Affected Components
* {*}geode-core{*}: {{VMStats50.java}} - core statistics collection
* {*}geode-gfsh{*}: {{MemberJvmOptions.java}} - JVM options configuration
* {*}geode-web{*}: Web-based management console
* {*}geode-pulse{*}: Monitoring dashboard
* {*}extensions/geode-modules{*}: Session state modules for Tomcat integration
h4. Affected Users
* {*}Operations Teams{*}: Must configure and maintain JVM flags across all
Geode deployments
* {*}Cloud Operators{*}: Face restrictions in containerized and serverless
environments
* {*}Security Teams{*}: Must approve exceptions to module encapsulation
policies
* {*}Embedded Users{*}: Applications embedding Geode (e.g., Spring Boot apps)
must propagate flags
* {*}Tomcat Users{*}: Applications using Geode session modules must configure
Tomcat with flags
h4. Current Workaround
All users must currently:
# Add {{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
to JVM arguments
# Document why this security exception is needed
# Maintain configuration across development, staging, and production
environments
# Update security exception approvals when Java versions change
h2. Benefits of Resolution
h3. 1. Security Improvements
* {*}Eliminates Module Violation{*}: Removes the last remaining
{{--add-opens}} flag requirement in Apache Geode
* {*}Reduces Attack Surface{*}: No longer exposes internal JDK packages to
reflection
* {*}Clean Security Audits{*}: Passes enterprise security scans without
exceptions
* {*}Compliance Achievement{*}: Meets security baselines for regulated
industries
* {*}Zero Trust Compatibility{*}: Compatible with zero-trust security
architectures
h3. 2. Deployment Simplification
* {*}No JVM Flags Required{*}: Geode runs on Java 17+ with zero
--{{{}add-opens-{}}} or --{{{}add-exports{}}} flags
* {*}Container Ready{*}: Deploy to any container platform without security
policy exceptions
* {*}Serverless Compatible{*}: Run in serverless environments without
restriction
* {*}Cloud Native{*}: Deploy to Kubernetes, OpenShift, Cloud Foundry without
special configuration
* {*}Simplified Documentation{*}: Remove complex JVM flag documentation and
troubleshooting guides
h3. 3. Operational Excellence
* {*}Reduced Configuration{*}: Fewer manual configuration steps for deployment
* {*}Faster Onboarding{*}: New users don't need to understand module system
complexities
* {*}Cleaner Deployments{*}: Standard JVM configuration works out of the box
* {*}Better Troubleshooting{*}: One less failure mode to diagnose
h3. 4. Future-Proofing
* {*}Forward Compatibility{*}: Ready for future Java releases that further
restrict reflection
* {*}Standards Compliance{*}: Fully compliant with Java Platform Module System
(JPMS) best practices
* {*}Maintenance Reduction{*}: No need to track Java version changes affecting
module flags
* {*}Strategic Positioning{*}: Positions Apache Geode as a modern, compliant
Java platform
h3. 5. Performance Potential
* {*}Reduced Reflection Overhead{*}: Eliminating reflection may improve
statistics collection performance
* {*}Better JIT Optimization{*}: Direct method calls allow better JVM
optimization
* {*}Faster Startup{*}: No reflection-based initialization overhead
h3. 6. Code Quality
* {*}Simpler Code{*}: Remove complex reflection logic
* {*}Type Safety{*}: Replace {{Method.invoke()}} with type-safe method calls
* {*}Better Maintainability{*}: Clearer code without reflection boilerplate
* {*}IDE Support{*}: Better code navigation and refactoring support
h2. Strategic Context
h3. Module Compliance Initiative
This issue is part of a comprehensive initiative to achieve full Java Module
System compliance in Apache Geode:
||Issue||Component||Flag Type||Status||
|GEODE-10519|UnsafeThreadLocal|{{--add-opens=java.base/java.lang=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|GEODE-10520|DirectBuffer|{{--add-exports=java.base/sun.nio.ch=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|GEODE-10521|AddressableMemoryManager|{{--add-opens=java.base/java.nio=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|*GEODE-10522*|*VMStats50*|{{--add-opens=jdk.management/...}}|{color:#ff0000}*THIS
ISSUE*{color}|
{*}Goal{*}: After resolving GEODE-10522, Apache Geode will require *ZERO*
module-opening or module-exporting flags to run on Java 17, or 21.
h3. Timeline Achievement
* {*}Started{*}: GEODE-10519 (UnsafeThreadLocal refactoring)
* {*}Progress{*}: 3 of 4 module violations eliminated (75% complete)
* {*}Target{*}: Complete module compliance in Apache Geode 2
* {*}Impact{*}: First major distributed data platform to achieve full JPMS
compliance
h2. Research Findings
h3. Package Analysis
The {{com.sun.management}} package structure in {{jdk.management}} module:
{code:java}
jdk.management module
├── com.sun.management (EXPORTED - public API)
│ ├── OperatingSystemMXBean (interface)
│ ├── UnixOperatingSystemMXBean (interface)
│ └── Other platform MXBeans
└── com.sun.management.internal (NOT EXPORTED - internal)
└── Implementation classes (requires --add-opens)
{code}
{*}Key Finding{*}: The {{com.sun.management}} package itself is *EXPORTED* by
the {{jdk.management}} module and contains public, documented APIs. Only the
{{com.sun.management.internal}} package requires special access.
h3. API Availability
The platform MXBean interfaces have been available since:
* Java 6: Initial platform MXBean APIs
* Java 9: Properly modularized in {{jdk.management}} module
* Java 11: Current LTS baseline for Apache Geode
* Java 17: Current LTS with continued support
* Java 21: Latest LTS with full JPMS enforcement
These are *documented, supported, public APIs* - not internal implementation
details.
h3. Cross-Platform Considerations
||Platform||Standard Metrics||Unix-Specific Metrics||
|Linux|✓ processCpuTime|✓ File descriptors|
|macOS|✓ processCpuTime|✓ File descriptors|
|Solaris|✓ processCpuTime|✓ File descriptors|
|AIX|✓ processCpuTime|✓ File descriptors|
|Windows|✓ processCpuTime|✗ File descriptors unavailable|
Current implementation gracefully handles platform differences - this behavior
must be preserved.
h3. Statistics Usage
The {{VMStats50}} statistics are consumed by:
* {*}MemberMBeanBridge{*}: JMX monitoring interface
* {*}Statistics Archiver{*}: Historical statistics collection
* {*}Geode Pulse{*}: Web-based monitoring dashboard
* {*}Geode Management API{*}: Programmatic monitoring
* {*}GemFire Management Console{*}: Commercial management tools
These statistics are critical for production monitoring and capacity planning.
h2. Success Criteria
h3. Primary Goals
# {*}Module Compliance{*}: Apache Geode runs on Java 17+ without
{{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
# {*}Functionality Preserved{*}: All VM statistics continue to be collected
with no data loss
# {*}Cross-Platform Support{*}: Works on Linux, macOS, Windows with
appropriate feature degradation
# {*}Java Version Support{*}: Works on Java 17, and 21 LTS releases
h3. Quality Requirements
# {*}Zero Regressions{*}: All existing tests pass
# {*}Performance{*}: Statistics collection performance equal or better than
current implementation
# {*}Documentation{*}: Clear migration notes for operators
# {*}Security{*}: Clean security audit results with no module violations
h3. Strategic Achievement
{panel:title=Mission
Accomplished|borderStyle=solid|borderColor=#00aa00|titleBGColor=#ccffcc|bgColor=#f0fff0}
*Apache Geode : Full Java Platform Module System Compliance*
After completing GEODE-10522, Apache Geode will be one of the first major
distributed data platforms to achieve:
* Zero {{--add-opens}} flags required
* Zero {{--add-exports}} flags required
* Full JPMS compliance on Java 17, 21
* Ready for future Java releases
* Container and serverless ready
* Enterprise security compliant{panel}
h2. Risk Assessment
h3. Implementation Risk
*MEDIUM* - While public APIs are available, care must be taken to:
* Preserve cross-platform compatibility (Unix vs Windows)
* Maintain graceful degradation if platform MXBeans unavailable
* Ensure no behavioral changes in statistics collection
* Verify API access doesn't require flags on all Java versions
h3. Deployment Risk
*LOW* - Changes are backward compatible:
* No configuration changes required for users
* Statistics collection continues to work identically
* Flag removal is transparent to applications
* No API changes to management interfaces
h3. Mitigation Strategy
* Comprehensive testing on multiple platforms (Linux, macOS, Windows)
* Testing on multiple Java versions (17, 21)
* Extensive integration testing with statistics consumers
* Gradual rollout through feature branch → develop → release
h2. Dependencies
h3. Prerequisite Issues
* GEODE-10519: UnsafeThreadLocal (COMPLETE)
* GEODE-10520: DirectBuffer (COMPLETE)
* GEODE-10521: AddressableMemoryManager (COMPLETE)
h2. Additional Context
h3. Reference Documentation
* [JEP 260: Encapsulate Most Internal APIs|https://openjdk.org/jeps/260]
* [JEP 261: Module System|https://openjdk.org/jeps/261]
* [JEP 403: Strongly Encapsulate JDK Internals|https://openjdk.org/jeps/403]
* [com.sun.management
Package|https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/package-summary.html]
h3. Related Issues
* GEODE-10519: Eliminate UnsafeThreadLocal reflection
* GEODE-10520: Eliminate DirectBuffer sun.nio.ch export
* GEODE-10521: Eliminate AddressableMemoryManager reflection
h3. Security Advisory
Current security impact of
{{{}--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED{}}}:
{panel:title=Security Risk
Assessment|borderStyle=solid|borderColor=#ff8800|titleBGColor=#ffeecc|bgColor=#fffef0}
{*}Risk Level{*}: MEDIUM (6/10)
{*}Threat Vectors{*}:
* Opens internal package to ALL-UNNAMED modules (not just Geode)
* Allows reflection on internal implementation details
* Bypasses module system security boundaries
* Creates audit exceptions in security scans
{*}Impact{*}:
* May be blocked in restricted environments
* Requires security exception approval
* Flagged in CVE scanners and security audits
* Prevents deployment to some cloud platforms
{*}Recommendation{*}: ELIMINATE flag to close security gap
{panel}
h2. Community Impact
h3. User Benefits
* {*}Simplified Deployment{*}: No JVM flag configuration required
* {*}Better Security{*}: Clean security scans without exceptions
* {*}Cloud Native{*}: Deploy anywhere without restrictions
* {*}Future Ready{*}: Compatible with future Java releases
h3. Contributor Benefits
* {*}Code Quality{*}: Simpler, more maintainable code
* {*}Less Complexity{*}: Fewer special cases to handle
* {*}Better Testing{*}: Type-safe code easier to test
* {*}Modern Standards{*}: Aligned with current Java best practices
h3. Strategic Benefits
* {*}Industry Leadership{*}: First major platform with full JPMS compliance
* {*}Enterprise Adoption{*}: Meets security requirements for large
organizations
* {*}Cloud Momentum{*}: Enables broader cloud platform support
* {*}Community Growth{*}: Easier for new users to adopt Geode
{panel:title=Document
Metadata|borderStyle=solid|borderColor=#cccccc|titleBGColor=#f0f0f0|bgColor=#fafafa}
{*}Document Type{*}: JIRA Planning Document
{*}Created{*}: November 14, 2025
{*}Phase{*}: Planning (Pre-Implementation)
{*}Status{*}: Ready for Design Review
{*}Next Step{*}: Architectural design and solution proposal
{panel}
was:
h2. Summary
Apache Geode currently requires the JVM flag
{{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}} to
collect VM statistics through the {{VMStats50}} class. This flag violates Java
Platform Module System (JPMS) encapsulation and should be eliminated to achieve
full module compliance.
h2. Problem Description
h3. Current State
The {{VMStats50}} class in {{geode-core}} uses reflection to access platform
MXBean methods for collecting VM statistics:
* File:
{{geode-core/src/main/java/org/apache/geode/internal/stats50/VMStats50.java}}
* Lines 155-185: Static initializer using reflection with
{{ClassPathLoader.forName()}}
* Line 172: Critical call to {{Method.setAccessible(true)}} on
{{getProcessCpuTime()}} method
* Lines 643-688: Runtime invocation using {{Method.invoke()}}
h3. Required JVM Flag
{code:java}
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
{code}
This flag is defined in {{MemberJvmOptions.java}} and is required for:
* All Geode server members
* All Geode locator members
* Embedded Geode instances (including those running in Tomcat containers)
* GFSH operations
h3. Technical Root Cause
The {{VMStats50}} class attempts to access the following platform MXBean
methods via reflection:
|Method|Purpose|Platform|
|{{getProcessCpuTime()}}|Process CPU time in nanoseconds|All platforms|
|{{getMaxFileDescriptorCount()}}|Maximum file descriptor limit|Unix-like only|
|{{getOpenFileDescriptorCount()}}|Currently open file descriptors|Unix-like
only|
The use of {{Method.setAccessible(true)}} on methods from the
{{jdk.management}} module requires the {{--add-opens}} flag to bypass strong
encapsulation introduced in Java 9+ (JEP 260, 261, 403).
h3. Why This Is a Problem
h4. 1. Security Violations
* {*}Module Encapsulation Breach{*}: The {{--add-opens}} flag explicitly
breaks Java's module system strong encapsulation, allowing reflection access to
internal implementation details
* {*}Attack Surface Expansion{*}: Opens the entire
{{com.sun.management.internal}} package to ALL-UNNAMED modules, not just Geode
code
* {*}Security Audit Failures{*}: Enterprise security scanners flag
{{--add-opens}} as a security risk requiring justification and exception
approval
* {*}Compliance Issues{*}: Violates security best practices in regulated
environments (financial services, healthcare, government)
h4. 2. Deployment Restrictions
* {*}Containerized Environments{*}: Some container platforms (Kubernetes,
Cloud Foundry) restrict or prohibit module-opening flags
* {*}Serverless Platforms{*}: AWS Lambda, Azure Functions, Google Cloud Run
may block JVM flags that weaken security boundaries
* {*}Corporate Security Policies{*}: Many enterprises have policies against
weakening module encapsulation
* {*}Cloud Platforms{*}: Azure, AWS, GCP security baselines may flag or reject
deployments with {{--add-opens}} flags
h4. 3. Operational Complexity
* {*}Configuration Burden{*}: Every Geode deployment requires manual JVM flag
configuration
* {*}Documentation Overhead{*}: Operators must understand why the flag is
needed and its security implications
* {*}Version Fragility{*}: Flag requirements may change across Java versions,
requiring deployment updates
* {*}Troubleshooting Difficulty{*}: Missing flag causes runtime failures that
may not be immediately obvious
h4. 4. Future Java Compatibility Risk
* {*}JEP 403 Trajectory{*}: Future Java versions may further restrict or
eliminate {{--add-opens}} capability
* {*}Deprecation Risk{*}: Reflection access to internal APIs is increasingly
discouraged by the OpenJDK project
* {*}Migration Burden{*}: Delaying resolution increases future migration
complexity and risk
h3. Impact Scope
h4. Affected Components
* {*}geode-core{*}: {{VMStats50.java}} - core statistics collection
* {*}geode-gfsh{*}: {{MemberJvmOptions.java}} - JVM options configuration
* {*}geode-web{*}: Web-based management console
* {*}geode-pulse{*}: Monitoring dashboard
* {*}extensions/geode-modules{*}: Session state modules for Tomcat integration
h4. Affected Users
* {*}Operations Teams{*}: Must configure and maintain JVM flags across all
Geode deployments
* {*}Cloud Operators{*}: Face restrictions in containerized and serverless
environments
* {*}Security Teams{*}: Must approve exceptions to module encapsulation
policies
* {*}Embedded Users{*}: Applications embedding Geode (e.g., Spring Boot apps)
must propagate flags
* {*}Tomcat Users{*}: Applications using Geode session modules must configure
Tomcat with flags
h4. Current Workaround
All users must currently:
# Add {{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
to JVM arguments
# Document why this security exception is needed
# Maintain configuration across development, staging, and production
environments
# Update security exception approvals when Java versions change
h2. Benefits of Resolution
h3. 1. Security Improvements
* {*}Eliminates Module Violation{*}: Removes the last remaining
{{--add-opens}} flag requirement in Apache Geode
* {*}Reduces Attack Surface{*}: No longer exposes internal JDK packages to
reflection
* {*}Clean Security Audits{*}: Passes enterprise security scans without
exceptions
* {*}Compliance Achievement{*}: Meets security baselines for regulated
industries
* {*}Zero Trust Compatibility{*}: Compatible with zero-trust security
architectures
h3. 2. Deployment Simplification
* {*}No JVM Flags Required{*}: Geode runs on Java 11+ with zero
{{-{-}add-opens{-}}} or {{-add-exports}} flags
* {*}Container Ready{*}: Deploy to any container platform without security
policy exceptions
* {*}Serverless Compatible{*}: Run in serverless environments without
restriction
* {*}Cloud Native{*}: Deploy to Kubernetes, OpenShift, Cloud Foundry without
special configuration
* {*}Simplified Documentation{*}: Remove complex JVM flag documentation and
troubleshooting guides
h3. 3. Operational Excellence
* {*}Reduced Configuration{*}: Fewer manual configuration steps for deployment
* {*}Faster Onboarding{*}: New users don't need to understand module system
complexities
* {*}Cleaner Deployments{*}: Standard JVM configuration works out of the box
* {*}Better Troubleshooting{*}: One less failure mode to diagnose
h3. 4. Future-Proofing
* {*}Forward Compatibility{*}: Ready for future Java releases that further
restrict reflection
* {*}Standards Compliance{*}: Fully compliant with Java Platform Module System
(JPMS) best practices
* {*}Maintenance Reduction{*}: No need to track Java version changes affecting
module flags
* {*}Strategic Positioning{*}: Positions Apache Geode as a modern, compliant
Java platform
h3. 5. Performance Potential
* {*}Reduced Reflection Overhead{*}: Eliminating reflection may improve
statistics collection performance
* {*}Better JIT Optimization{*}: Direct method calls allow better JVM
optimization
* {*}Faster Startup{*}: No reflection-based initialization overhead
h3. 6. Code Quality
* {*}Simpler Code{*}: Remove complex reflection logic
* {*}Type Safety{*}: Replace {{Method.invoke()}} with type-safe method calls
* {*}Better Maintainability{*}: Clearer code without reflection boilerplate
* {*}IDE Support{*}: Better code navigation and refactoring support
h2. Strategic Context
h3. Module Compliance Initiative
This issue is part of a comprehensive initiative to achieve full Java Module
System compliance in Apache Geode:
||Issue||Component||Flag Type||Status||
|GEODE-10519|UnsafeThreadLocal|{{--add-opens=java.base/java.lang=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|GEODE-10520|DirectBuffer|{{--add-exports=java.base/sun.nio.ch=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|GEODE-10521|AddressableMemoryManager|{{--add-opens=java.base/java.nio=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
|*GEODE-10522*|*VMStats50*|{{--add-opens=jdk.management/...}}|{color:#FF0000}*THIS
ISSUE*{color}|
{*}Goal{*}: After resolving GEODE-10522, Apache Geode will require *ZERO*
module-opening or module-exporting flags to run on Java 11, 17, or 21.
h3. Timeline Achievement
* {*}Started{*}: GEODE-10519 (UnsafeThreadLocal refactoring)
* {*}Progress{*}: 3 of 4 module violations eliminated (75% complete)
* {*}Target{*}: Complete module compliance in Apache Geode 2
* {*}Impact{*}: First major distributed data platform to achieve full JPMS
compliance
h2. Research Findings
h3. Package Analysis
The {{com.sun.management}} package structure in {{jdk.management}} module:
{code:java}
jdk.management module
├── com.sun.management (EXPORTED - public API)
│ ├── OperatingSystemMXBean (interface)
│ ├── UnixOperatingSystemMXBean (interface)
│ └── Other platform MXBeans
└── com.sun.management.internal (NOT EXPORTED - internal)
└── Implementation classes (requires --add-opens)
{code}
{*}Key Finding{*}: The {{com.sun.management}} package itself is *EXPORTED* by
the {{jdk.management}} module and contains public, documented APIs. Only the
{{com.sun.management.internal}} package requires special access.
h3. API Availability
The platform MXBean interfaces have been available since:
* Java 6: Initial platform MXBean APIs
* Java 9: Properly modularized in {{jdk.management}} module
* Java 11: Current LTS baseline for Apache Geode
* Java 17: Current LTS with continued support
* Java 21: Latest LTS with full JPMS enforcement
These are *documented, supported, public APIs* - not internal implementation
details.
h3. Cross-Platform Considerations
||Platform||Standard Metrics||Unix-Specific Metrics||
|Linux|✓ processCpuTime|✓ File descriptors|
|macOS|✓ processCpuTime|✓ File descriptors|
|Solaris|✓ processCpuTime|✓ File descriptors|
|AIX|✓ processCpuTime|✓ File descriptors|
|Windows|✓ processCpuTime|✗ File descriptors unavailable|
Current implementation gracefully handles platform differences - this behavior
must be preserved.
h3. Statistics Usage
The {{VMStats50}} statistics are consumed by:
* {*}MemberMBeanBridge{*}: JMX monitoring interface
* {*}Statistics Archiver{*}: Historical statistics collection
* {*}Geode Pulse{*}: Web-based monitoring dashboard
* {*}Geode Management API{*}: Programmatic monitoring
* {*}GemFire Management Console{*}: Commercial management tools
These statistics are critical for production monitoring and capacity planning.
h2. Success Criteria
h3. Primary Goals
# {*}Module Compliance{*}: Apache Geode runs on Java 11+ without
{{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
# {*}Functionality Preserved{*}: All VM statistics continue to be collected
with no data loss
# {*}Cross-Platform Support{*}: Works on Linux, macOS, Windows with
appropriate feature degradation
# {*}Java Version Support{*}: Works on Java 17, and 21 LTS releases
h3. Quality Requirements
# {*}Zero Regressions{*}: All existing tests pass
# {*}Performance{*}: Statistics collection performance equal or better than
current implementation
# {*}Documentation{*}: Clear migration notes for operators
# {*}Security{*}: Clean security audit results with no module violations
h3. Strategic Achievement
{panel:title=Mission
Accomplished|borderStyle=solid|borderColor=#00aa00|titleBGColor=#ccffcc|bgColor=#f0fff0}
*Apache Geode : Full Java Platform Module System Compliance*
After completing GEODE-10522, Apache Geode will be one of the first major
distributed data platforms to achieve:
* Zero {{--add-opens}} flags required
* Zero {{--add-exports}} flags required
* Full JPMS compliance on Java 17, 21
* Ready for future Java releases
* Container and serverless ready
* Enterprise security compliant{panel}
h2. Risk Assessment
h3. Implementation Risk
*MEDIUM* - While public APIs are available, care must be taken to:
* Preserve cross-platform compatibility (Unix vs Windows)
* Maintain graceful degradation if platform MXBeans unavailable
* Ensure no behavioral changes in statistics collection
* Verify API access doesn't require flags on all Java versions
h3. Deployment Risk
*LOW* - Changes are backward compatible:
* No configuration changes required for users
* Statistics collection continues to work identically
* Flag removal is transparent to applications
* No API changes to management interfaces
h3. Mitigation Strategy
* Comprehensive testing on multiple platforms (Linux, macOS, Windows)
* Testing on multiple Java versions (11, 17, 21)
* Extensive integration testing with statistics consumers
* Gradual rollout through feature branch → develop → release
h2. Dependencies
h3. Prerequisite Issues
* GEODE-10519: UnsafeThreadLocal (COMPLETE)
* GEODE-10520: DirectBuffer (COMPLETE)
* GEODE-10521: AddressableMemoryManager (COMPLETE)
h3. Related Work
* Java Module System (JPMS) compliance initiative
* Security audit remediation
* Container deployment improvements
h3. Blocking Issues
*None* - This issue can be implemented independently
h2. Open Questions for Design Phase
# Should we maintain reflection as a fallback if direct access fails?
# What is the appropriate error handling if platform MXBeans are unavailable?
# Should we add new statistics or monitoring capabilities while refactoring?
# Do we need feature flags to control the new implementation?
# What is the rollback strategy if issues are found post-deployment?
h2. Labels
* {{module-compliance}}
* {{security}}
* {{statistics}}
* {{java-11}}
* {{java-17}}
* {{java-21}}
* {{container-ready}}
* {{jep-403}}
h2. Priority
*Major* - Affects security posture, deployment flexibility, and strategic
positioning
h2. Target Version
Apache Geode 1.18.0
h2. Additional Context
h3. Reference Documentation
* [JEP 260: Encapsulate Most Internal APIs|https://openjdk.org/jeps/260]
* [JEP 261: Module System|https://openjdk.org/jeps/261]
* [JEP 403: Strongly Encapsulate JDK Internals|https://openjdk.org/jeps/403]
* [com.sun.management
Package|https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/package-summary.html]
h3. Related Issues
* GEODE-10519: Eliminate UnsafeThreadLocal reflection
* GEODE-10520: Eliminate DirectBuffer sun.nio.ch export
* GEODE-10521: Eliminate AddressableMemoryManager reflection
h3. Security Advisory
Current security impact of
{{{}--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED{}}}:
{panel:title=Security Risk
Assessment|borderStyle=solid|borderColor=#ff8800|titleBGColor=#ffeecc|bgColor=#fffef0}
{*}Risk Level{*}: MEDIUM (6/10)
{*}Threat Vectors{*}:
* Opens internal package to ALL-UNNAMED modules (not just Geode)
* Allows reflection on internal implementation details
* Bypasses module system security boundaries
* Creates audit exceptions in security scans
{*}Impact{*}:
* May be blocked in restricted environments
* Requires security exception approval
* Flagged in CVE scanners and security audits
* Prevents deployment to some cloud platforms
{*}Recommendation{*}: ELIMINATE flag to close security gap
{panel}
h2. Community Impact
h3. User Benefits
* {*}Simplified Deployment{*}: No JVM flag configuration required
* {*}Better Security{*}: Clean security scans without exceptions
* {*}Cloud Native{*}: Deploy anywhere without restrictions
* {*}Future Ready{*}: Compatible with future Java releases
h3. Contributor Benefits
* {*}Code Quality{*}: Simpler, more maintainable code
* {*}Less Complexity{*}: Fewer special cases to handle
* {*}Better Testing{*}: Type-safe code easier to test
* {*}Modern Standards{*}: Aligned with current Java best practices
h3. Strategic Benefits
* {*}Industry Leadership{*}: First major platform with full JPMS compliance
* {*}Enterprise Adoption{*}: Meets security requirements for large
organizations
* {*}Cloud Momentum{*}: Enables broader cloud platform support
* {*}Community Growth{*}: Easier for new users to adopt Geode
—
{panel:title=Document
Metadata|borderStyle=solid|borderColor=#cccccc|titleBGColor=#f0f0f0|bgColor=#fafafa}
{*}Document Type{*}: JIRA Planning Document
{*}Created{*}: November 14, 2025
{*}Phase{*}: Planning (Pre-Implementation)
{*}Status{*}: Ready for Design Review
{*}Next Step{*}: Architectural design and solution proposal
{panel}
> Eliminate VMStats50 Reflection to Remove --add-opens JVM Flag Requirement
> -------------------------------------------------------------------------
>
> Key: GEODE-10522
> URL: https://issues.apache.org/jira/browse/GEODE-10522
> Project: Geode
> Issue Type: Improvement
> Reporter: Jinwoo Hwang
> Assignee: Jinwoo Hwang
> Priority: Major
> Fix For: 2.1.0
>
>
> h2. Summary
> Apache Geode currently requires the JVM flag
> {{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}} to
> collect VM statistics through the {{VMStats50}} class. This flag violates
> Java Platform Module System (JPMS) encapsulation and should be eliminated to
> achieve full module compliance.
> h2. Problem Description
> h3. Current State
> The {{VMStats50}} class in {{geode-core}} uses reflection to access platform
> MXBean methods for collecting VM statistics:
> * File:
> {{geode-core/src/main/java/org/apache/geode/internal/stats50/VMStats50.java}}
> * Lines 155-185: Static initializer using reflection with
> {{ClassPathLoader.forName()}}
> * Line 172: Critical call to {{Method.setAccessible(true)}} on
> {{getProcessCpuTime()}} method
> * Lines 643-688: Runtime invocation using {{Method.invoke()}}
> h3. Required JVM Flag
> {code:java}
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> This flag is defined in {{MemberJvmOptions.java}} and is required for:
> * All Geode server members
> * All Geode locator members
> * Embedded Geode instances (including those running in Tomcat containers)
> * GFSH operations
> h3. Technical Root Cause
> The {{VMStats50}} class attempts to access the following platform MXBean
> methods via reflection:
> |Method|Purpose|Platform|
> |{{getProcessCpuTime()}}|Process CPU time in nanoseconds|All platforms|
> |{{getMaxFileDescriptorCount()}}|Maximum file descriptor limit|Unix-like only|
> |{{getOpenFileDescriptorCount()}}|Currently open file descriptors|Unix-like
> only|
> The use of {{Method.setAccessible(true)}} on methods from the
> {{jdk.management}} module requires the {{--add-opens}} flag to bypass strong
> encapsulation introduced in Java 9+ (JEP 260, 261, 403).
> h3. Why This Is a Problem
> h4. 1. Security Violations
> * {*}Module Encapsulation Breach{*}: The {{--add-opens}} flag explicitly
> breaks Java's module system strong encapsulation, allowing reflection access
> to internal implementation details
> * {*}Attack Surface Expansion{*}: Opens the entire
> {{com.sun.management.internal}} package to ALL-UNNAMED modules, not just
> Geode code
> * {*}Security Audit Failures{*}: Enterprise security scanners flag
> {{--add-opens}} as a security risk requiring justification and exception
> approval
> * {*}Compliance Issues{*}: Violates security best practices in regulated
> environments (financial services, healthcare, government)
> h4. 2. Deployment Restrictions
> * {*}Containerized Environments{*}: Some container platforms (Kubernetes,
> Cloud Foundry) restrict or prohibit module-opening flags
> * {*}Serverless Platforms{*}: AWS Lambda, Azure Functions, Google Cloud Run
> may block JVM flags that weaken security boundaries
> * {*}Corporate Security Policies{*}: Many enterprises have policies against
> weakening module encapsulation
> * {*}Cloud Platforms{*}: Azure, AWS, GCP security baselines may flag or
> reject deployments with {{--add-opens}} flags
> h4. 3. Operational Complexity
> * {*}Configuration Burden{*}: Every Geode deployment requires manual JVM
> flag configuration
> * {*}Documentation Overhead{*}: Operators must understand why the flag is
> needed and its security implications
> * {*}Version Fragility{*}: Flag requirements may change across Java
> versions, requiring deployment updates
> * {*}Troubleshooting Difficulty{*}: Missing flag causes runtime failures
> that may not be immediately obvious
> h4. 4. Future Java Compatibility Risk
> * {*}JEP 403 Trajectory{*}: Future Java versions may further restrict or
> eliminate {{--add-opens}} capability
> * {*}Deprecation Risk{*}: Reflection access to internal APIs is increasingly
> discouraged by the OpenJDK project
> * {*}Migration Burden{*}: Delaying resolution increases future migration
> complexity and risk
> h3. Impact Scope
> h4. Affected Components
> * {*}geode-core{*}: {{VMStats50.java}} - core statistics collection
> * {*}geode-gfsh{*}: {{MemberJvmOptions.java}} - JVM options configuration
> * {*}geode-web{*}: Web-based management console
> * {*}geode-pulse{*}: Monitoring dashboard
> * {*}extensions/geode-modules{*}: Session state modules for Tomcat
> integration
> h4. Affected Users
> * {*}Operations Teams{*}: Must configure and maintain JVM flags across all
> Geode deployments
> * {*}Cloud Operators{*}: Face restrictions in containerized and serverless
> environments
> * {*}Security Teams{*}: Must approve exceptions to module encapsulation
> policies
> * {*}Embedded Users{*}: Applications embedding Geode (e.g., Spring Boot
> apps) must propagate flags
> * {*}Tomcat Users{*}: Applications using Geode session modules must
> configure Tomcat with flags
> h4. Current Workaround
> All users must currently:
> # Add {{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> to JVM arguments
> # Document why this security exception is needed
> # Maintain configuration across development, staging, and production
> environments
> # Update security exception approvals when Java versions change
> h2. Benefits of Resolution
> h3. 1. Security Improvements
> * {*}Eliminates Module Violation{*}: Removes the last remaining
> {{--add-opens}} flag requirement in Apache Geode
> * {*}Reduces Attack Surface{*}: No longer exposes internal JDK packages to
> reflection
> * {*}Clean Security Audits{*}: Passes enterprise security scans without
> exceptions
> * {*}Compliance Achievement{*}: Meets security baselines for regulated
> industries
> * {*}Zero Trust Compatibility{*}: Compatible with zero-trust security
> architectures
> h3. 2. Deployment Simplification
> * {*}No JVM Flags Required{*}: Geode runs on Java 17+ with zero
> --{{{}add-opens-{}}} or --{{{}add-exports{}}} flags
> * {*}Container Ready{*}: Deploy to any container platform without security
> policy exceptions
> * {*}Serverless Compatible{*}: Run in serverless environments without
> restriction
> * {*}Cloud Native{*}: Deploy to Kubernetes, OpenShift, Cloud Foundry without
> special configuration
> * {*}Simplified Documentation{*}: Remove complex JVM flag documentation and
> troubleshooting guides
> h3. 3. Operational Excellence
> * {*}Reduced Configuration{*}: Fewer manual configuration steps for
> deployment
> * {*}Faster Onboarding{*}: New users don't need to understand module system
> complexities
> * {*}Cleaner Deployments{*}: Standard JVM configuration works out of the box
> * {*}Better Troubleshooting{*}: One less failure mode to diagnose
> h3. 4. Future-Proofing
> * {*}Forward Compatibility{*}: Ready for future Java releases that further
> restrict reflection
> * {*}Standards Compliance{*}: Fully compliant with Java Platform Module
> System (JPMS) best practices
> * {*}Maintenance Reduction{*}: No need to track Java version changes
> affecting module flags
> * {*}Strategic Positioning{*}: Positions Apache Geode as a modern, compliant
> Java platform
> h3. 5. Performance Potential
> * {*}Reduced Reflection Overhead{*}: Eliminating reflection may improve
> statistics collection performance
> * {*}Better JIT Optimization{*}: Direct method calls allow better JVM
> optimization
> * {*}Faster Startup{*}: No reflection-based initialization overhead
> h3. 6. Code Quality
> * {*}Simpler Code{*}: Remove complex reflection logic
> * {*}Type Safety{*}: Replace {{Method.invoke()}} with type-safe method calls
> * {*}Better Maintainability{*}: Clearer code without reflection boilerplate
> * {*}IDE Support{*}: Better code navigation and refactoring support
> h2. Strategic Context
> h3. Module Compliance Initiative
> This issue is part of a comprehensive initiative to achieve full Java Module
> System compliance in Apache Geode:
> ||Issue||Component||Flag Type||Status||
> |GEODE-10519|UnsafeThreadLocal|{{--add-opens=java.base/java.lang=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
> |GEODE-10520|DirectBuffer|{{--add-exports=java.base/sun.nio.ch=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
> |GEODE-10521|AddressableMemoryManager|{{--add-opens=java.base/java.nio=ALL-UNNAMED}}|{color:#008000}*COMPLETE*{color}|
> |*GEODE-10522*|*VMStats50*|{{--add-opens=jdk.management/...}}|{color:#ff0000}*THIS
> ISSUE*{color}|
> {*}Goal{*}: After resolving GEODE-10522, Apache Geode will require *ZERO*
> module-opening or module-exporting flags to run on Java 17, or 21.
> h3. Timeline Achievement
> * {*}Started{*}: GEODE-10519 (UnsafeThreadLocal refactoring)
> * {*}Progress{*}: 3 of 4 module violations eliminated (75% complete)
> * {*}Target{*}: Complete module compliance in Apache Geode 2
> * {*}Impact{*}: First major distributed data platform to achieve full JPMS
> compliance
> h2. Research Findings
> h3. Package Analysis
> The {{com.sun.management}} package structure in {{jdk.management}} module:
> {code:java}
> jdk.management module
> ├── com.sun.management (EXPORTED - public API)
> │ ├── OperatingSystemMXBean (interface)
> │ ├── UnixOperatingSystemMXBean (interface)
> │ └── Other platform MXBeans
> └── com.sun.management.internal (NOT EXPORTED - internal)
> └── Implementation classes (requires --add-opens)
> {code}
> {*}Key Finding{*}: The {{com.sun.management}} package itself is *EXPORTED* by
> the {{jdk.management}} module and contains public, documented APIs. Only the
> {{com.sun.management.internal}} package requires special access.
> h3. API Availability
> The platform MXBean interfaces have been available since:
> * Java 6: Initial platform MXBean APIs
> * Java 9: Properly modularized in {{jdk.management}} module
> * Java 11: Current LTS baseline for Apache Geode
> * Java 17: Current LTS with continued support
> * Java 21: Latest LTS with full JPMS enforcement
> These are *documented, supported, public APIs* - not internal implementation
> details.
> h3. Cross-Platform Considerations
> ||Platform||Standard Metrics||Unix-Specific Metrics||
> |Linux|✓ processCpuTime|✓ File descriptors|
> |macOS|✓ processCpuTime|✓ File descriptors|
> |Solaris|✓ processCpuTime|✓ File descriptors|
> |AIX|✓ processCpuTime|✓ File descriptors|
> |Windows|✓ processCpuTime|✗ File descriptors unavailable|
> Current implementation gracefully handles platform differences - this
> behavior must be preserved.
> h3. Statistics Usage
> The {{VMStats50}} statistics are consumed by:
> * {*}MemberMBeanBridge{*}: JMX monitoring interface
> * {*}Statistics Archiver{*}: Historical statistics collection
> * {*}Geode Pulse{*}: Web-based monitoring dashboard
> * {*}Geode Management API{*}: Programmatic monitoring
> * {*}GemFire Management Console{*}: Commercial management tools
> These statistics are critical for production monitoring and capacity planning.
> h2. Success Criteria
> h3. Primary Goals
> # {*}Module Compliance{*}: Apache Geode runs on Java 17+ without
> {{--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> # {*}Functionality Preserved{*}: All VM statistics continue to be collected
> with no data loss
> # {*}Cross-Platform Support{*}: Works on Linux, macOS, Windows with
> appropriate feature degradation
> # {*}Java Version Support{*}: Works on Java 17, and 21 LTS releases
> h3. Quality Requirements
> # {*}Zero Regressions{*}: All existing tests pass
> # {*}Performance{*}: Statistics collection performance equal or better than
> current implementation
> # {*}Documentation{*}: Clear migration notes for operators
> # {*}Security{*}: Clean security audit results with no module violations
> h3. Strategic Achievement
> {panel:title=Mission
> Accomplished|borderStyle=solid|borderColor=#00aa00|titleBGColor=#ccffcc|bgColor=#f0fff0}
> *Apache Geode : Full Java Platform Module System Compliance*
> After completing GEODE-10522, Apache Geode will be one of the first major
> distributed data platforms to achieve:
> * Zero {{--add-opens}} flags required
> * Zero {{--add-exports}} flags required
> * Full JPMS compliance on Java 17, 21
> * Ready for future Java releases
> * Container and serverless ready
> * Enterprise security compliant{panel}
> h2. Risk Assessment
> h3. Implementation Risk
> *MEDIUM* - While public APIs are available, care must be taken to:
> * Preserve cross-platform compatibility (Unix vs Windows)
> * Maintain graceful degradation if platform MXBeans unavailable
> * Ensure no behavioral changes in statistics collection
> * Verify API access doesn't require flags on all Java versions
> h3. Deployment Risk
> *LOW* - Changes are backward compatible:
> * No configuration changes required for users
> * Statistics collection continues to work identically
> * Flag removal is transparent to applications
> * No API changes to management interfaces
> h3. Mitigation Strategy
> * Comprehensive testing on multiple platforms (Linux, macOS, Windows)
> * Testing on multiple Java versions (17, 21)
> * Extensive integration testing with statistics consumers
> * Gradual rollout through feature branch → develop → release
> h2. Dependencies
> h3. Prerequisite Issues
> * GEODE-10519: UnsafeThreadLocal (COMPLETE)
> * GEODE-10520: DirectBuffer (COMPLETE)
> * GEODE-10521: AddressableMemoryManager (COMPLETE)
> h2. Additional Context
> h3. Reference Documentation
> * [JEP 260: Encapsulate Most Internal APIs|https://openjdk.org/jeps/260]
> * [JEP 261: Module System|https://openjdk.org/jeps/261]
> * [JEP 403: Strongly Encapsulate JDK Internals|https://openjdk.org/jeps/403]
> * [com.sun.management
> Package|https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/package-summary.html]
> h3. Related Issues
> * GEODE-10519: Eliminate UnsafeThreadLocal reflection
> * GEODE-10520: Eliminate DirectBuffer sun.nio.ch export
> * GEODE-10521: Eliminate AddressableMemoryManager reflection
> h3. Security Advisory
> Current security impact of
> {{{}--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED{}}}:
> {panel:title=Security Risk
> Assessment|borderStyle=solid|borderColor=#ff8800|titleBGColor=#ffeecc|bgColor=#fffef0}
> {*}Risk Level{*}: MEDIUM (6/10)
> {*}Threat Vectors{*}:
> * Opens internal package to ALL-UNNAMED modules (not just Geode)
> * Allows reflection on internal implementation details
> * Bypasses module system security boundaries
> * Creates audit exceptions in security scans
> {*}Impact{*}:
> * May be blocked in restricted environments
> * Requires security exception approval
> * Flagged in CVE scanners and security audits
> * Prevents deployment to some cloud platforms
> {*}Recommendation{*}: ELIMINATE flag to close security gap
> {panel}
> h2. Community Impact
> h3. User Benefits
> * {*}Simplified Deployment{*}: No JVM flag configuration required
> * {*}Better Security{*}: Clean security scans without exceptions
> * {*}Cloud Native{*}: Deploy anywhere without restrictions
> * {*}Future Ready{*}: Compatible with future Java releases
> h3. Contributor Benefits
> * {*}Code Quality{*}: Simpler, more maintainable code
> * {*}Less Complexity{*}: Fewer special cases to handle
> * {*}Better Testing{*}: Type-safe code easier to test
> * {*}Modern Standards{*}: Aligned with current Java best practices
> h3. Strategic Benefits
> * {*}Industry Leadership{*}: First major platform with full JPMS compliance
> * {*}Enterprise Adoption{*}: Meets security requirements for large
> organizations
> * {*}Cloud Momentum{*}: Enables broader cloud platform support
> * {*}Community Growth{*}: Easier for new users to adopt Geode
>
> {panel:title=Document
> Metadata|borderStyle=solid|borderColor=#cccccc|titleBGColor=#f0f0f0|bgColor=#fafafa}
> {*}Document Type{*}: JIRA Planning Document
> {*}Created{*}: November 14, 2025
> {*}Phase{*}: Planning (Pre-Implementation)
> {*}Status{*}: Ready for Design Review
> {*}Next Step{*}: Architectural design and solution proposal
> {panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
