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
