Here is a discussion from Google Guava project about compiling module-info.java in Java 9+ and including it in a jar with classes compiled for Java 8.
https://github.com/google/guava/issues/2970 On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > I like Dan’s idea! I would rather we work towards the correct solution. > > > On Oct 10, 2018, at 1:22 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > > #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 > >
