Goal: Run Geode on Java 11 (GEODE-3 <https://issues.apache.org/jira/browse/GEODE-3>).
Problem: Java 8 allows Geode (and its 3rd party libraries) full access to all Java APIs, including internal APIs. However, Java 11 restricts access to many of these APIs by default. Solution #1: Remove all usage of restricted APIs from all Geode code, and find replacements for all 3rd party libraries that depend on restricted APIs. Solution #2: Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies on restricted APIs. Solution #3: Update all existing public and personal scripts, wrappers, IDE configurations, test harnesses, and other java invocations to add a handful of --add-opens flags to the java commandline to override the default Java 11 restrictions. Solution #4: Use the MIT-licensed permit-reflect <https://github.com/nqzero/permit-reflect> library to programmatically override Java 11’s API restrictions. In terms of feasibility: #1 would be extremely difficult. Geode has a large number of dependencies on internal Java APIs in critical areas, and replacing them would be time-consuming, potentially destabilizing, and very likely to negatively impact performance. #2 is complex because we still need Geode to run on Java 8, so not using any Java 11 features seems safer than introducing multi-version jars, cross-compilation, or separate releases per target Java platform. #3 is easy enough to implement in scripts that are under source control, but users or developers that have their own IDE configurations or test environments may struggle to understand why they are getting errors and how to fix them. #4 restores full Java8-like permissions with essentially just a change to main() method. Which strategy do you prefer? Java 11 test jobs are in the pipeline <https://concourse.apachegeode-ci.info/teams/main/pipelines/develop> as of today — let’s make them green! -Owen
