You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@pivotal.io> on 2018/10/10 19:20:39 UTC
[DISCUSS] permit-reflect vs --add-opens for Java 11 support
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
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Anthony Baker <ab...@pivotal.io>.
Also, for #3, what does it look like to run a client application? IOW, what are the command-line arguments needed?
Anthony
> On Oct 10, 2018, at 1:29 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> Do you have a listed of restricted API’s that are used by Geode? Which libraries used by Geode are affected? Are these run-time only warnings or actual errors?
>
> Anthony
>
>
>
>> On Oct 10, 2018, at 12:20 PM, Owen Nichols <on...@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
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Anthony Baker <ab...@pivotal.io>.
Do you have a listed of restricted API’s that are used by Geode? Which libraries used by Geode are affected? Are these run-time only warnings or actual errors?
Anthony
> On Oct 10, 2018, at 12:20 PM, Owen Nichols <on...@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
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Robert Houghton <rh...@pivotal.io>.
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" <on...@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
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Dan Smith <ds...@pivotal.io>.
Regarding -add-opens for reflection - I misunderstood. I thought you were
saying we need --add-opens for *all* reflection. But it sounds like we are
doing reflection on the JDK classes themselves. If that is the case I agree
we need --add-opens until we fix that.
-Dan
On Mon, Nov 5, 2018 at 8:41 AM Jinmei Liao <ji...@pivotal.io> wrote:
> Dan, are you saying we do or do not need --add-opens for reflection? The
> opens directive is for open up classes in its own modules for reflection. I
> don't think we can use that to open up jdk's packages, can we?
>
> On Fri, Nov 2, 2018 at 3:52 PM Dan Smith <ds...@pivotal.io> wrote:
>
> > I guess I'm ok with documenting the --add-opens workaround in the short
> > term, so that users can start playing with Geode on JDK 11. Maybe we
> should
> > indicate the JDK 11 support is experimental. I guess in addition to that,
> > we are going to document that users should put Geode on the classpath and
> > not the module path? Has anyone tested putting Geode on the module path?
> >
> > There are actually two ways to reserve a module name - you can create the
> > module-info.java, OR you can just add an Automatic-Module-Name header to
> > the your jar manifest. I think that would probably be the minimum we
> should
> > do before we start telling users to put geode on the module path.
> >
> > Regarding reflection - I don't think we don't need--add-opens for that.
> > Users just need to use the opens directive to mark their packages as
> > available for reflection.
> >
> > -Dan
> >
> >
> > On Fri, Nov 2, 2018 at 8:49 AM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > Galen, you are right, --add-opens is necessary for accessing the
> private
> > > fields and methods when doing deep reflection which is used a lot in
> our
> > > serialization code.
> > >
> > > Let me step back and explain the scope of what we are trying to do
> here.
> > > We all know to be fully java11 compliant, we need to:
> > > 1. remove all the java internal API dependencies in geode itself
> > > 2. upgrade all the 3rd party libraries that was using java internal API
> > as
> > > well.
> > > 3. properly modularize geode and include module-info in the manifest.
> > >
> > > The bad news is: we are NOT doing any of them YET, and even if we
> > achieved
> > > all the above, from what I read, these "--add-opens" are still
> necessary
> > if
> > > we need to allow our code to do deep reflection at runtime.
> > >
> > > What we are trying to achieve here is:
> > > 1. get a green jdk11 pipeline up and running first. We need to be able
> to
> > > use jdk11 to run all our tests first, so that we can begin working on
> > the 3
> > > things in the above list.
> > > 2. our users can download our code and starting running in jdk11 (with
> > some
> > > additional configuration of course), this way, we can get the community
> > to
> > > experiment with geode in jdk11 and improve upon it.
> > >
> > > We are only trying to discuss how to achieve the bottom 2 goals first
> > here.
> > >
> > > Cheers.
> > >
> > > On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan <
> gosullivan@pivotal.io>
> > > wrote:
> > >
> > > > I did a little more reading, and it sounds like we should create an
> > > > module-info.java to reserve the proper name for those customers who
> are
> > > > using Java 9+. See this article[1] for a description of what can go
> > wrong
> > > > if people start using the automatic package without us having
> declared
> > a
> > > > name. I think a module-info should be necessary for *any* level of
> Java
> > > 9+
> > > > support.
> > > >
> > > > Jinmei, please correct me if I'm wrong here, but I believe
> --add-opens
> > is
> > > > necessary for the reflection that we use in PDX auto-serialization,
> and
> > > > probably elsewhere as well. This would make it necessary for any Java
> > > > program communicating with Geode that uses automatic serialization to
> > > have
> > > > --add-opens. I don't understand all that well what level of
> reflection
> > is
> > > > available in Java 11, but it will probably take quite a bit of time
> to
> > > do a
> > > > complete fix.
> > > >
> > > > +1 to this approach, provided we create a module-info.java
> > > >
> > > > [1]:
> > https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> > > >
> > > >
> > > > On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao <ji...@pivotal.io>
> wrote:
> > > >
> > > > > And one disclaimer I have to add is that these "--add-opens" are
> the
> > > ones
> > > > > uncovered by our current set of tests, there might be more needed
> in
> > > > areas
> > > > > that are not covered by our tests. So to say the most, our current
> > > jdk11
> > > > > support is still in beta mode.
> > > > >
> > > > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > > > >
> > > > > > 1) yes, gfsh script will need to be updated to add these
> > > > configurations.
> > > > > > 2) yes, these ad-opens are required to run geode clients as well.
> > We
> > > > will
> > > > > > need to document them.
> > > > > >
> > > > > > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io>
> > wrote:
> > > > > >
> > > > > >> A couple of questions:
> > > > > >>
> > > > > >> 1) Are you proposing changing gfsh start server to automatically
> > add
> > > > > these
> > > > > >> add-opens, or are you suggesting users will have to do that?
> > > > > >> 2) Are these add-opens required for running a geode client?
> > > > > >>
> > > > > >> -Dan
> > > > > >>
> > > > > >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <
> > > prhomberg@apache.org
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > In case anyone else's email broke the thread, below is a link
> to
> > > the
> > > > > >> > previous thread in the mail archive for context.
> > > > > >> >
> > > > > >> > https://markmail.org/thread/xt224pvavxu3d54p
> > > > > >> >
> > > > > >> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <
> jiliao@pivotal.io>
> > > > > wrote:
> > > > > >> >
> > > > > >> > > We will need to wrap up this discussion with a decision.
> Looks
> > > > like
> > > > > we
> > > > > >> > are
> > > > > >> > > skeptical about #4, and it's proven to work with #3 since
> our
> > > > > current
> > > > > >> > jdk11
> > > > > >> > > pipeline is green with this approach.
> > > > > >> > >
> > > > > >> > > Can I propose we do #3 and document the extra configuration
> > > needed
> > > > > for
> > > > > >> > > jdk11 for now and then work towards #1 and #2?
> > > > > >> > >
> > > > > >> > > Here is the extra configuration to the jvm that are need to
> > run
> > > > > geode
> > > > > >> > under
> > > > > >> > > jdk11:
> > > > > >> > >
> > > > > >> > >
> > > > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > > > > >> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > > > > >> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > > > > >> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> > > > > >> > >
> > > > > >> > > comments? votes?
> > > > > >> > >
> > > > > >> > > Thanks!
> > > > > >> > >
> > > > > >> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > > > > >> > > sai.boorlagadda@gmail.com>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > >Do we know what third party libraries are using java
> > > internals
> > > > > that
> > > > > >> > >we
> > > > > >> > > > might
> > > > > >> > > > have problems with? #2 isn't going to work for those
> > > >libraries,
> > > > > >> unless
> > > > > >> > > > they also add a module-info.class. So maybe we >will need
> to
> > > do
> > > > #3
> > > > > >> for
> > > > > >> > > > third-party libraries?
> > > > > >> > > >
> > > > > >> > > > Adding these third-party libs on module path[1] rather
> than
> > > > class
> > > > > >> path
> > > > > >> > > > seems to address this issue.
> > > > > >> > > >
> > > > > >> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > > > > >> > > automatic-modules
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Cheers
> > > > > >> > >
> > > > > >> > > Jinmei
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > >
> > > > > > Jinmei
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
Dan, are you saying we do or do not need --add-opens for reflection? The
opens directive is for open up classes in its own modules for reflection. I
don't think we can use that to open up jdk's packages, can we?
On Fri, Nov 2, 2018 at 3:52 PM Dan Smith <ds...@pivotal.io> wrote:
> I guess I'm ok with documenting the --add-opens workaround in the short
> term, so that users can start playing with Geode on JDK 11. Maybe we should
> indicate the JDK 11 support is experimental. I guess in addition to that,
> we are going to document that users should put Geode on the classpath and
> not the module path? Has anyone tested putting Geode on the module path?
>
> There are actually two ways to reserve a module name - you can create the
> module-info.java, OR you can just add an Automatic-Module-Name header to
> the your jar manifest. I think that would probably be the minimum we should
> do before we start telling users to put geode on the module path.
>
> Regarding reflection - I don't think we don't need--add-opens for that.
> Users just need to use the opens directive to mark their packages as
> available for reflection.
>
> -Dan
>
>
> On Fri, Nov 2, 2018 at 8:49 AM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > Galen, you are right, --add-opens is necessary for accessing the private
> > fields and methods when doing deep reflection which is used a lot in our
> > serialization code.
> >
> > Let me step back and explain the scope of what we are trying to do here.
> > We all know to be fully java11 compliant, we need to:
> > 1. remove all the java internal API dependencies in geode itself
> > 2. upgrade all the 3rd party libraries that was using java internal API
> as
> > well.
> > 3. properly modularize geode and include module-info in the manifest.
> >
> > The bad news is: we are NOT doing any of them YET, and even if we
> achieved
> > all the above, from what I read, these "--add-opens" are still necessary
> if
> > we need to allow our code to do deep reflection at runtime.
> >
> > What we are trying to achieve here is:
> > 1. get a green jdk11 pipeline up and running first. We need to be able to
> > use jdk11 to run all our tests first, so that we can begin working on
> the 3
> > things in the above list.
> > 2. our users can download our code and starting running in jdk11 (with
> some
> > additional configuration of course), this way, we can get the community
> to
> > experiment with geode in jdk11 and improve upon it.
> >
> > We are only trying to discuss how to achieve the bottom 2 goals first
> here.
> >
> > Cheers.
> >
> > On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan <go...@pivotal.io>
> > wrote:
> >
> > > I did a little more reading, and it sounds like we should create an
> > > module-info.java to reserve the proper name for those customers who are
> > > using Java 9+. See this article[1] for a description of what can go
> wrong
> > > if people start using the automatic package without us having declared
> a
> > > name. I think a module-info should be necessary for *any* level of Java
> > 9+
> > > support.
> > >
> > > Jinmei, please correct me if I'm wrong here, but I believe --add-opens
> is
> > > necessary for the reflection that we use in PDX auto-serialization, and
> > > probably elsewhere as well. This would make it necessary for any Java
> > > program communicating with Geode that uses automatic serialization to
> > have
> > > --add-opens. I don't understand all that well what level of reflection
> is
> > > available in Java 11, but it will probably take quite a bit of time to
> > do a
> > > complete fix.
> > >
> > > +1 to this approach, provided we create a module-info.java
> > >
> > > [1]:
> https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> > >
> > >
> > > On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao <ji...@pivotal.io> wrote:
> > >
> > > > And one disclaimer I have to add is that these "--add-opens" are the
> > ones
> > > > uncovered by our current set of tests, there might be more needed in
> > > areas
> > > > that are not covered by our tests. So to say the most, our current
> > jdk11
> > > > support is still in beta mode.
> > > >
> > > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io>
> wrote:
> > > >
> > > > > 1) yes, gfsh script will need to be updated to add these
> > > configurations.
> > > > > 2) yes, these ad-opens are required to run geode clients as well.
> We
> > > will
> > > > > need to document them.
> > > > >
> > > > > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io>
> wrote:
> > > > >
> > > > >> A couple of questions:
> > > > >>
> > > > >> 1) Are you proposing changing gfsh start server to automatically
> add
> > > > these
> > > > >> add-opens, or are you suggesting users will have to do that?
> > > > >> 2) Are these add-opens required for running a geode client?
> > > > >>
> > > > >> -Dan
> > > > >>
> > > > >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <
> > prhomberg@apache.org
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > In case anyone else's email broke the thread, below is a link to
> > the
> > > > >> > previous thread in the mail archive for context.
> > > > >> >
> > > > >> > https://markmail.org/thread/xt224pvavxu3d54p
> > > > >> >
> > > > >> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io>
> > > > wrote:
> > > > >> >
> > > > >> > > We will need to wrap up this discussion with a decision. Looks
> > > like
> > > > we
> > > > >> > are
> > > > >> > > skeptical about #4, and it's proven to work with #3 since our
> > > > current
> > > > >> > jdk11
> > > > >> > > pipeline is green with this approach.
> > > > >> > >
> > > > >> > > Can I propose we do #3 and document the extra configuration
> > needed
> > > > for
> > > > >> > > jdk11 for now and then work towards #1 and #2?
> > > > >> > >
> > > > >> > > Here is the extra configuration to the jvm that are need to
> run
> > > > geode
> > > > >> > under
> > > > >> > > jdk11:
> > > > >> > >
> > > > >> > >
> > > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > > > >> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > > > >> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > > > >> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> > > > >> > >
> > > > >> > > comments? votes?
> > > > >> > >
> > > > >> > > Thanks!
> > > > >> > >
> > > > >> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > > > >> > > sai.boorlagadda@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > >Do we know what third party libraries are using java
> > internals
> > > > that
> > > > >> > >we
> > > > >> > > > might
> > > > >> > > > have problems with? #2 isn't going to work for those
> > >libraries,
> > > > >> unless
> > > > >> > > > they also add a module-info.class. So maybe we >will need to
> > do
> > > #3
> > > > >> for
> > > > >> > > > third-party libraries?
> > > > >> > > >
> > > > >> > > > Adding these third-party libs on module path[1] rather than
> > > class
> > > > >> path
> > > > >> > > > seems to address this issue.
> > > > >> > > >
> > > > >> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > > > >> > > automatic-modules
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Cheers
> > > > >> > >
> > > > >> > > Jinmei
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Dan Smith <ds...@pivotal.io>.
I guess I'm ok with documenting the --add-opens workaround in the short
term, so that users can start playing with Geode on JDK 11. Maybe we should
indicate the JDK 11 support is experimental. I guess in addition to that,
we are going to document that users should put Geode on the classpath and
not the module path? Has anyone tested putting Geode on the module path?
There are actually two ways to reserve a module name - you can create the
module-info.java, OR you can just add an Automatic-Module-Name header to
the your jar manifest. I think that would probably be the minimum we should
do before we start telling users to put geode on the module path.
Regarding reflection - I don't think we don't need--add-opens for that.
Users just need to use the opens directive to mark their packages as
available for reflection.
-Dan
On Fri, Nov 2, 2018 at 8:49 AM Jinmei Liao <ji...@pivotal.io> wrote:
> Galen, you are right, --add-opens is necessary for accessing the private
> fields and methods when doing deep reflection which is used a lot in our
> serialization code.
>
> Let me step back and explain the scope of what we are trying to do here.
> We all know to be fully java11 compliant, we need to:
> 1. remove all the java internal API dependencies in geode itself
> 2. upgrade all the 3rd party libraries that was using java internal API as
> well.
> 3. properly modularize geode and include module-info in the manifest.
>
> The bad news is: we are NOT doing any of them YET, and even if we achieved
> all the above, from what I read, these "--add-opens" are still necessary if
> we need to allow our code to do deep reflection at runtime.
>
> What we are trying to achieve here is:
> 1. get a green jdk11 pipeline up and running first. We need to be able to
> use jdk11 to run all our tests first, so that we can begin working on the 3
> things in the above list.
> 2. our users can download our code and starting running in jdk11 (with some
> additional configuration of course), this way, we can get the community to
> experiment with geode in jdk11 and improve upon it.
>
> We are only trying to discuss how to achieve the bottom 2 goals first here.
>
> Cheers.
>
> On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan <go...@pivotal.io>
> wrote:
>
> > I did a little more reading, and it sounds like we should create an
> > module-info.java to reserve the proper name for those customers who are
> > using Java 9+. See this article[1] for a description of what can go wrong
> > if people start using the automatic package without us having declared a
> > name. I think a module-info should be necessary for *any* level of Java
> 9+
> > support.
> >
> > Jinmei, please correct me if I'm wrong here, but I believe --add-opens is
> > necessary for the reflection that we use in PDX auto-serialization, and
> > probably elsewhere as well. This would make it necessary for any Java
> > program communicating with Geode that uses automatic serialization to
> have
> > --add-opens. I don't understand all that well what level of reflection is
> > available in Java 11, but it will probably take quite a bit of time to
> do a
> > complete fix.
> >
> > +1 to this approach, provided we create a module-info.java
> >
> > [1]: https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> >
> >
> > On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > And one disclaimer I have to add is that these "--add-opens" are the
> ones
> > > uncovered by our current set of tests, there might be more needed in
> > areas
> > > that are not covered by our tests. So to say the most, our current
> jdk11
> > > support is still in beta mode.
> > >
> > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io> wrote:
> > >
> > > > 1) yes, gfsh script will need to be updated to add these
> > configurations.
> > > > 2) yes, these ad-opens are required to run geode clients as well. We
> > will
> > > > need to document them.
> > > >
> > > > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io> wrote:
> > > >
> > > >> A couple of questions:
> > > >>
> > > >> 1) Are you proposing changing gfsh start server to automatically add
> > > these
> > > >> add-opens, or are you suggesting users will have to do that?
> > > >> 2) Are these add-opens required for running a geode client?
> > > >>
> > > >> -Dan
> > > >>
> > > >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <
> prhomberg@apache.org
> > >
> > > >> wrote:
> > > >>
> > > >> > In case anyone else's email broke the thread, below is a link to
> the
> > > >> > previous thread in the mail archive for context.
> > > >> >
> > > >> > https://markmail.org/thread/xt224pvavxu3d54p
> > > >> >
> > > >> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io>
> > > wrote:
> > > >> >
> > > >> > > We will need to wrap up this discussion with a decision. Looks
> > like
> > > we
> > > >> > are
> > > >> > > skeptical about #4, and it's proven to work with #3 since our
> > > current
> > > >> > jdk11
> > > >> > > pipeline is green with this approach.
> > > >> > >
> > > >> > > Can I propose we do #3 and document the extra configuration
> needed
> > > for
> > > >> > > jdk11 for now and then work towards #1 and #2?
> > > >> > >
> > > >> > > Here is the extra configuration to the jvm that are need to run
> > > geode
> > > >> > under
> > > >> > > jdk11:
> > > >> > >
> > > >> > >
> > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > > >> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > > >> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > > >> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> > > >> > >
> > > >> > > comments? votes?
> > > >> > >
> > > >> > > Thanks!
> > > >> > >
> > > >> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > > >> > > sai.boorlagadda@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > >Do we know what third party libraries are using java
> internals
> > > that
> > > >> > >we
> > > >> > > > might
> > > >> > > > have problems with? #2 isn't going to work for those
> >libraries,
> > > >> unless
> > > >> > > > they also add a module-info.class. So maybe we >will need to
> do
> > #3
> > > >> for
> > > >> > > > third-party libraries?
> > > >> > > >
> > > >> > > > Adding these third-party libs on module path[1] rather than
> > class
> > > >> path
> > > >> > > > seems to address this issue.
> > > >> > > >
> > > >> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > > >> > > automatic-modules
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Cheers
> > > >> > >
> > > >> > > Jinmei
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
Galen, you are right, --add-opens is necessary for accessing the private
fields and methods when doing deep reflection which is used a lot in our
serialization code.
Let me step back and explain the scope of what we are trying to do here.
We all know to be fully java11 compliant, we need to:
1. remove all the java internal API dependencies in geode itself
2. upgrade all the 3rd party libraries that was using java internal API as
well.
3. properly modularize geode and include module-info in the manifest.
The bad news is: we are NOT doing any of them YET, and even if we achieved
all the above, from what I read, these "--add-opens" are still necessary if
we need to allow our code to do deep reflection at runtime.
What we are trying to achieve here is:
1. get a green jdk11 pipeline up and running first. We need to be able to
use jdk11 to run all our tests first, so that we can begin working on the 3
things in the above list.
2. our users can download our code and starting running in jdk11 (with some
additional configuration of course), this way, we can get the community to
experiment with geode in jdk11 and improve upon it.
We are only trying to discuss how to achieve the bottom 2 goals first here.
Cheers.
On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan <go...@pivotal.io>
wrote:
> I did a little more reading, and it sounds like we should create an
> module-info.java to reserve the proper name for those customers who are
> using Java 9+. See this article[1] for a description of what can go wrong
> if people start using the automatic package without us having declared a
> name. I think a module-info should be necessary for *any* level of Java 9+
> support.
>
> Jinmei, please correct me if I'm wrong here, but I believe --add-opens is
> necessary for the reflection that we use in PDX auto-serialization, and
> probably elsewhere as well. This would make it necessary for any Java
> program communicating with Geode that uses automatic serialization to have
> --add-opens. I don't understand all that well what level of reflection is
> available in Java 11, but it will probably take quite a bit of time to do a
> complete fix.
>
> +1 to this approach, provided we create a module-info.java
>
> [1]: https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>
>
> On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > And one disclaimer I have to add is that these "--add-opens" are the ones
> > uncovered by our current set of tests, there might be more needed in
> areas
> > that are not covered by our tests. So to say the most, our current jdk11
> > support is still in beta mode.
> >
> > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > 1) yes, gfsh script will need to be updated to add these
> configurations.
> > > 2) yes, these ad-opens are required to run geode clients as well. We
> will
> > > need to document them.
> > >
> > > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io> wrote:
> > >
> > >> A couple of questions:
> > >>
> > >> 1) Are you proposing changing gfsh start server to automatically add
> > these
> > >> add-opens, or are you suggesting users will have to do that?
> > >> 2) Are these add-opens required for running a geode client?
> > >>
> > >> -Dan
> > >>
> > >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <prhomberg@apache.org
> >
> > >> wrote:
> > >>
> > >> > In case anyone else's email broke the thread, below is a link to the
> > >> > previous thread in the mail archive for context.
> > >> >
> > >> > https://markmail.org/thread/xt224pvavxu3d54p
> > >> >
> > >> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io>
> > wrote:
> > >> >
> > >> > > We will need to wrap up this discussion with a decision. Looks
> like
> > we
> > >> > are
> > >> > > skeptical about #4, and it's proven to work with #3 since our
> > current
> > >> > jdk11
> > >> > > pipeline is green with this approach.
> > >> > >
> > >> > > Can I propose we do #3 and document the extra configuration needed
> > for
> > >> > > jdk11 for now and then work towards #1 and #2?
> > >> > >
> > >> > > Here is the extra configuration to the jvm that are need to run
> > geode
> > >> > under
> > >> > > jdk11:
> > >> > >
> > >> > >
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > >> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > >> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > >> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> > >> > >
> > >> > > comments? votes?
> > >> > >
> > >> > > Thanks!
> > >> > >
> > >> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > >> > > sai.boorlagadda@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > >Do we know what third party libraries are using java internals
> > that
> > >> > >we
> > >> > > > might
> > >> > > > have problems with? #2 isn't going to work for those >libraries,
> > >> unless
> > >> > > > they also add a module-info.class. So maybe we >will need to do
> #3
> > >> for
> > >> > > > third-party libraries?
> > >> > > >
> > >> > > > Adding these third-party libs on module path[1] rather than
> class
> > >> path
> > >> > > > seems to address this issue.
> > >> > > >
> > >> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > >> > > automatic-modules
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Cheers
> > >> > >
> > >> > > Jinmei
> > >> > >
> > >> >
> > >>
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
--
Cheers
Jinmei
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Galen O'Sullivan <go...@pivotal.io>.
I did a little more reading, and it sounds like we should create an
module-info.java to reserve the proper name for those customers who are
using Java 9+. See this article[1] for a description of what can go wrong
if people start using the automatic package without us having declared a
name. I think a module-info should be necessary for *any* level of Java 9+
support.
Jinmei, please correct me if I'm wrong here, but I believe --add-opens is
necessary for the reflection that we use in PDX auto-serialization, and
probably elsewhere as well. This would make it necessary for any Java
program communicating with Geode that uses automatic serialization to have
--add-opens. I don't understand all that well what level of reflection is
available in Java 11, but it will probably take quite a bit of time to do a
complete fix.
+1 to this approach, provided we create a module-info.java
[1]: https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao <ji...@pivotal.io> wrote:
> And one disclaimer I have to add is that these "--add-opens" are the ones
> uncovered by our current set of tests, there might be more needed in areas
> that are not covered by our tests. So to say the most, our current jdk11
> support is still in beta mode.
>
> On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > 1) yes, gfsh script will need to be updated to add these configurations.
> > 2) yes, these ad-opens are required to run geode clients as well. We will
> > need to document them.
> >
> > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io> wrote:
> >
> >> A couple of questions:
> >>
> >> 1) Are you proposing changing gfsh start server to automatically add
> these
> >> add-opens, or are you suggesting users will have to do that?
> >> 2) Are these add-opens required for running a geode client?
> >>
> >> -Dan
> >>
> >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <pr...@apache.org>
> >> wrote:
> >>
> >> > In case anyone else's email broke the thread, below is a link to the
> >> > previous thread in the mail archive for context.
> >> >
> >> > https://markmail.org/thread/xt224pvavxu3d54p
> >> >
> >> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io>
> wrote:
> >> >
> >> > > We will need to wrap up this discussion with a decision. Looks like
> we
> >> > are
> >> > > skeptical about #4, and it's proven to work with #3 since our
> current
> >> > jdk11
> >> > > pipeline is green with this approach.
> >> > >
> >> > > Can I propose we do #3 and document the extra configuration needed
> for
> >> > > jdk11 for now and then work towards #1 and #2?
> >> > >
> >> > > Here is the extra configuration to the jvm that are need to run
> geode
> >> > under
> >> > > jdk11:
> >> > >
> >> > > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> >> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> >> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> >> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> >> > >
> >> > > comments? votes?
> >> > >
> >> > > Thanks!
> >> > >
> >> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> >> > > sai.boorlagadda@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > >Do we know what third party libraries are using java internals
> that
> >> > >we
> >> > > > might
> >> > > > have problems with? #2 isn't going to work for those >libraries,
> >> unless
> >> > > > they also add a module-info.class. So maybe we >will need to do #3
> >> for
> >> > > > third-party libraries?
> >> > > >
> >> > > > Adding these third-party libs on module path[1] rather than class
> >> path
> >> > > > seems to address this issue.
> >> > > >
> >> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> >> > > automatic-modules
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Cheers
> >> > >
> >> > > Jinmei
> >> > >
> >> >
> >>
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
And one disclaimer I have to add is that these "--add-opens" are the ones
uncovered by our current set of tests, there might be more needed in areas
that are not covered by our tests. So to say the most, our current jdk11
support is still in beta mode.
On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao <ji...@pivotal.io> wrote:
> 1) yes, gfsh script will need to be updated to add these configurations.
> 2) yes, these ad-opens are required to run geode clients as well. We will
> need to document them.
>
> On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io> wrote:
>
>> A couple of questions:
>>
>> 1) Are you proposing changing gfsh start server to automatically add these
>> add-opens, or are you suggesting users will have to do that?
>> 2) Are these add-opens required for running a geode client?
>>
>> -Dan
>>
>> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <pr...@apache.org>
>> wrote:
>>
>> > In case anyone else's email broke the thread, below is a link to the
>> > previous thread in the mail archive for context.
>> >
>> > https://markmail.org/thread/xt224pvavxu3d54p
>> >
>> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>> >
>> > > We will need to wrap up this discussion with a decision. Looks like we
>> > are
>> > > skeptical about #4, and it's proven to work with #3 since our current
>> > jdk11
>> > > pipeline is green with this approach.
>> > >
>> > > Can I propose we do #3 and document the extra configuration needed for
>> > > jdk11 for now and then work towards #1 and #2?
>> > >
>> > > Here is the extra configuration to the jvm that are need to run geode
>> > under
>> > > jdk11:
>> > >
>> > > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
>> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
>> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
>> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
>> > >
>> > > comments? votes?
>> > >
>> > > Thanks!
>> > >
>> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
>> > > sai.boorlagadda@gmail.com>
>> > > wrote:
>> > >
>> > > > >Do we know what third party libraries are using java internals that
>> > >we
>> > > > might
>> > > > have problems with? #2 isn't going to work for those >libraries,
>> unless
>> > > > they also add a module-info.class. So maybe we >will need to do #3
>> for
>> > > > third-party libraries?
>> > > >
>> > > > Adding these third-party libs on module path[1] rather than class
>> path
>> > > > seems to address this issue.
>> > > >
>> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
>> > > automatic-modules
>> > > >
>> > >
>> > >
>> > > --
>> > > Cheers
>> > >
>> > > Jinmei
>> > >
>> >
>>
>
>
> --
> Cheers
>
> Jinmei
>
--
Cheers
Jinmei
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
1) yes, gfsh script will need to be updated to add these configurations.
2) yes, these ad-opens are required to run geode clients as well. We will
need to document them.
On Thu, Nov 1, 2018 at 10:31 AM Dan Smith <ds...@pivotal.io> wrote:
> A couple of questions:
>
> 1) Are you proposing changing gfsh start server to automatically add these
> add-opens, or are you suggesting users will have to do that?
> 2) Are these add-opens required for running a geode client?
>
> -Dan
>
> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <pr...@apache.org>
> wrote:
>
> > In case anyone else's email broke the thread, below is a link to the
> > previous thread in the mail archive for context.
> >
> > https://markmail.org/thread/xt224pvavxu3d54p
> >
> > On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > We will need to wrap up this discussion with a decision. Looks like we
> > are
> > > skeptical about #4, and it's proven to work with #3 since our current
> > jdk11
> > > pipeline is green with this approach.
> > >
> > > Can I propose we do #3 and document the extra configuration needed for
> > > jdk11 for now and then work towards #1 and #2?
> > >
> > > Here is the extra configuration to the jvm that are need to run geode
> > under
> > > jdk11:
> > >
> > > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> > >
> > > comments? votes?
> > >
> > > Thanks!
> > >
> > > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > > sai.boorlagadda@gmail.com>
> > > wrote:
> > >
> > > > >Do we know what third party libraries are using java internals that
> > >we
> > > > might
> > > > have problems with? #2 isn't going to work for those >libraries,
> unless
> > > > they also add a module-info.class. So maybe we >will need to do #3
> for
> > > > third-party libraries?
> > > >
> > > > Adding these third-party libs on module path[1] rather than class
> path
> > > > seems to address this issue.
> > > >
> > > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > > automatic-modules
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
--
Cheers
Jinmei
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Dan Smith <ds...@pivotal.io>.
A couple of questions:
1) Are you proposing changing gfsh start server to automatically add these
add-opens, or are you suggesting users will have to do that?
2) Are these add-opens required for running a geode client?
-Dan
On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg <pr...@apache.org>
wrote:
> In case anyone else's email broke the thread, below is a link to the
> previous thread in the mail archive for context.
>
> https://markmail.org/thread/xt224pvavxu3d54p
>
> On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > We will need to wrap up this discussion with a decision. Looks like we
> are
> > skeptical about #4, and it's proven to work with #3 since our current
> jdk11
> > pipeline is green with this approach.
> >
> > Can I propose we do #3 and document the extra configuration needed for
> > jdk11 for now and then work towards #1 and #2?
> >
> > Here is the extra configuration to the jvm that are need to run geode
> under
> > jdk11:
> >
> > --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> > --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> > --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> > --add-opens=java.base/java.lang.module=ALL-UNNAMED"
> >
> > comments? votes?
> >
> > Thanks!
> >
> > On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> > sai.boorlagadda@gmail.com>
> > wrote:
> >
> > > >Do we know what third party libraries are using java internals that
> >we
> > > might
> > > have problems with? #2 isn't going to work for those >libraries, unless
> > > they also add a module-info.class. So maybe we >will need to do #3 for
> > > third-party libraries?
> > >
> > > Adding these third-party libs on module path[1] rather than class path
> > > seems to address this issue.
> > >
> > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> > automatic-modules
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
Re: [PROPOSAL] --add-opens for Java 11 support
Posted by Patrick Rhomberg <pr...@apache.org>.
In case anyone else's email broke the thread, below is a link to the
previous thread in the mail archive for context.
https://markmail.org/thread/xt224pvavxu3d54p
On Thu, Nov 1, 2018 at 9:35 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> We will need to wrap up this discussion with a decision. Looks like we are
> skeptical about #4, and it's proven to work with #3 since our current jdk11
> pipeline is green with this approach.
>
> Can I propose we do #3 and document the extra configuration needed for
> jdk11 for now and then work towards #1 and #2?
>
> Here is the extra configuration to the jvm that are need to run geode under
> jdk11:
>
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
> --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
> --add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
> --add-opens=java.base/java.lang.module=ALL-UNNAMED"
>
> comments? votes?
>
> Thanks!
>
> On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > >Do we know what third party libraries are using java internals that >we
> > might
> > have problems with? #2 isn't going to work for those >libraries, unless
> > they also add a module-info.class. So maybe we >will need to do #3 for
> > third-party libraries?
> >
> > Adding these third-party libs on module path[1] rather than class path
> > seems to address this issue.
> >
> > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> automatic-modules
> >
>
>
> --
> Cheers
>
> Jinmei
>
[PROPOSAL] --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
We will need to wrap up this discussion with a decision. Looks like we are
skeptical about #4, and it's proven to work with #3 since our current jdk11
pipeline is green with this approach.
Can I propose we do #3 and document the extra configuration needed for
jdk11 for now and then work towards #1 and #2?
Here is the extra configuration to the jvm that are need to run geode under
jdk11:
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
--add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED"
--add-opens=java.base/jdk.internal.module=ALL-UNNAMED"
--add-opens=java.base/java.lang.module=ALL-UNNAMED"
comments? votes?
Thanks!
On Thu, Oct 11, 2018 at 10:20 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> >Do we know what third party libraries are using java internals that >we
> might
> have problems with? #2 isn't going to work for those >libraries, unless
> they also add a module-info.class. So maybe we >will need to do #3 for
> third-party libraries?
>
> Adding these third-party libs on module path[1] rather than class path
> seems to address this issue.
>
> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules
>
--
Cheers
Jinmei
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Sai Boorlagadda <sa...@gmail.com>.
>Do we know what third party libraries are using java internals that >we might
have problems with? #2 isn't going to work for those >libraries, unless
they also add a module-info.class. So maybe we >will need to do #3 for
third-party libraries?
Adding these third-party libs on module path[1] rather than class path
seems to address this issue.
[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Patrick Rhomberg <pr...@apache.org>.
I'm with Galen on this one. As nice as it would be to be able to say "This
is what we'll do," I don't think any of these is going to be the proverbial
silver bullet.
I think we should, in priority order, (#1) remove what restricted API calls
we can, (#2) adopt the module system and properly declare our dependencies
on APIs that we do need, and (#3) update our wrappers where me must,
perhaps in cases like Dan has noticed, where it's not even our own
consumption of an internal API that would be problematic.
On Thu, Oct 11, 2018 at 9:49 AM, Dan Smith <ds...@pivotal.io> wrote:
> Do we know what third party libraries are using java internals that we
> might have problems with? #2 isn't going to work for those libraries,
> unless they also add a module-info.class. So maybe we will need to do #3
> for third-party libraries?
>
> For #2, maybe we don't have to go whole hog on adding module-info to all of
> our modules right away. We can identify and isolate our use of internal JDK
> classes to some small modules with few dependencies. For example, we could
> move our use of Unsafe to a geode-off-heap module and just add a
> module-info for that. We probably ought to have that code in a separate
> module anyway!
>
> -Dan
>
> On Wed, Oct 10, 2018 at 2:59 PM Jinmei Liao <ji...@pivotal.io> wrote:
>
> > #3 first and then work towards #1, then #2. We can document what
> > "--add-open" options needs to be added to start client if running with
> > jdk11+ in the meantime.
> >
> > I also have reservations about how #4 works. If it works, it is a good
> > alternation for #3.
> >
> > On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagadda <
> sai.boorlagadda@gmail.com
> > >
> > wrote:
> >
> > > +1 to Dan's idea if its possible.
> > >
> > > There is a maven plugin to invoke javac twice with respective java
> > targets.
> > >
> > >
> > https://maven.apache.org/plugins/maven-compiler-plugin/
> examples/module-info.html
> > >
> > >
> > > On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan <
> gosullivan@pivotal.io>
> > > wrote:
> > >
> > > > er, lost the end of that first sentence there. I think that reducing
> > > > dependencies on Unsafe &c is a good goal regardless.
> > > >
> > > > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <
> > gosullivan@pivotal.io>
> > > > wrote:
> > > >
> > > > > #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 <jbarrett@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 <
> jbarrett@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 <ds...@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 <
> > > 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
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Dan Smith <ds...@pivotal.io>.
Do we know what third party libraries are using java internals that we
might have problems with? #2 isn't going to work for those libraries,
unless they also add a module-info.class. So maybe we will need to do #3
for third-party libraries?
For #2, maybe we don't have to go whole hog on adding module-info to all of
our modules right away. We can identify and isolate our use of internal JDK
classes to some small modules with few dependencies. For example, we could
move our use of Unsafe to a geode-off-heap module and just add a
module-info for that. We probably ought to have that code in a separate
module anyway!
-Dan
On Wed, Oct 10, 2018 at 2:59 PM Jinmei Liao <ji...@pivotal.io> wrote:
> #3 first and then work towards #1, then #2. We can document what
> "--add-open" options needs to be added to start client if running with
> jdk11+ in the meantime.
>
> I also have reservations about how #4 works. If it works, it is a good
> alternation for #3.
>
> On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagadda <sai.boorlagadda@gmail.com
> >
> wrote:
>
> > +1 to Dan's idea if its possible.
> >
> > There is a maven plugin to invoke javac twice with respective java
> targets.
> >
> >
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
> >
> >
> > On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan <go...@pivotal.io>
> > wrote:
> >
> > > er, lost the end of that first sentence there. I think that reducing
> > > dependencies on Unsafe &c is a good goal regardless.
> > >
> > > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <
> gosullivan@pivotal.io>
> > > wrote:
> > >
> > > > #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 <jb...@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 <jb...@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 <ds...@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 <
> > 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
> > > >> >
> > > >> >
> > > >>
> > > >
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Jinmei Liao <ji...@pivotal.io>.
#3 first and then work towards #1, then #2. We can document what
"--add-open" options needs to be added to start client if running with
jdk11+ in the meantime.
I also have reservations about how #4 works. If it works, it is a good
alternation for #3.
On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagadda <sa...@gmail.com>
wrote:
> +1 to Dan's idea if its possible.
>
> There is a maven plugin to invoke javac twice with respective java targets.
>
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
>
>
> On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan <go...@pivotal.io>
> wrote:
>
> > er, lost the end of that first sentence there. I think that reducing
> > dependencies on Unsafe &c is a good goal regardless.
> >
> > On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <go...@pivotal.io>
> > wrote:
> >
> > > #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 <jb...@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 <jb...@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 <ds...@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 <
> 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
> > >> >
> > >> >
> > >>
> > >
> >
>
--
Cheers
Jinmei
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Sai Boorlagadda <sa...@gmail.com>.
+1 to Dan's idea if its possible.
There is a maven plugin to invoke javac twice with respective java targets.
https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan <go...@pivotal.io>
wrote:
> er, lost the end of that first sentence there. I think that reducing
> dependencies on Unsafe &c is a good goal regardless.
>
> On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <go...@pivotal.io>
> wrote:
>
> > #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 <jb...@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 <jb...@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 <ds...@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 <on...@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
> >> >
> >> >
> >>
> >
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Galen O'Sullivan <go...@pivotal.io>.
er, lost the end of that first sentence there. I think that reducing
dependencies on Unsafe &c is a good goal regardless.
On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan <go...@pivotal.io>
wrote:
> #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 <jb...@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 <jb...@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 <ds...@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 <on...@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
>> >
>> >
>>
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Galen O'Sullivan <go...@pivotal.io>.
#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 <jb...@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 <jb...@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 <ds...@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 <on...@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
> >
> >
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <jb...@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 <ds...@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 <on...@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
>
>
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Jacob Barrett <jb...@pivotal.io>.
I like Dan’s idea! I would rather we work towards the correct solution.
> On Oct 10, 2018, at 1:22 PM, Dan Smith <ds...@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 <on...@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
Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support
Posted by Dan Smith <ds...@pivotal.io>.
#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 <on...@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