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 <jil...@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 <jil...@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 <dsm...@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 <prhomb...@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 <jil...@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.boorlaga...@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 >
