#2 seems like the least hacky way to continue using things like sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and bundle it? This would also help consumers of geode that want to use Java 9 modules.
I'm a little bit sceptical of this permit-reflect libary, seeing as it's been around for about 1 month, has 0 tests in the source that I can see, and seems to be tripling down on relying on sun.misc.Unsafe to do stuff. I'd be inclined to do #3 before this. -Dan On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols <onich...@pivotal.io> wrote: > 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
