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
