geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <jil...@pivotal.io>
Subject Re: [PROPOSAL] --add-opens for Java 11 support
Date Thu, 01 Nov 2018 17:57:18 GMT
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 <jiliao@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 <dsmith@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

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