geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Houghton <rhough...@pivotal.io>
Subject Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Date Wed, 10 Oct 2018 19:46:47 GMT
I vote for #1, with #4 as a stopgap

Isn't a  goal of Java 11 support in Geode that we can use the new Java
modules system? If so, let's actually try and get there. I think stability
would actually improve by using public API instead of internals, and
performance fears are just that: fears, until proven otherwise


On Oct 10, 2018 12:20, "Owen Nichols" <onichols@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message