#1 sounds awesome but may be unrealistic given our advertised feature set. I think that reducing dependencies on Unsafe &c
If we can conditionally use Jigsaw modules for Java versions later than 8 while maintaining Java 8 compatiblity, that seems like the best solution. +2 to Dan's idea if it allows this. On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 > > > > >
