Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no longer works, although this API was marked

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Gradle/groovy are known to have problems with the restricted module access of b148.   You can get around this specific problem by using the environment variable _JAVA_OPTIONS=--add-opens=java.base/java.lang=ALL-UNNAMED   The packages that you need to open depend on what Java methods your

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

> On Dec 9, 2016, at 7:32 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Thanks for your review. Comments below.. > > On 10/12/16, 2:18 AM, Mandy Chung wrote: >>> On Dec 9, 2016, at 12:49 AM, Sundararajan >>>

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

Hello Mandy, In Copy-java.base.gmk. Modules.gmk is no longer needed. JMOD_* varaibles are no longer used. In Main.gmk, it would be good with a comment explaining why the jmods need java.base-copy. Something like: # All modules include the main license files from java.base. Otherwise I'm

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

> On Dec 9, 2016, at 11:51 PM, Erik Joelsson wrote: > > Hello Mandy, > > In Copy-java.base.gmk. Modules.gmk is no longer needed. JMOD_* varaibles are > no longer used. > Good catch. > In Main.gmk, it would be good with a comment explaining why the jmods need >

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 12/9/16 3:21 PM, Uwe Schindler wrote: > The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, > but it does not solve the underlying issue. Apache Solr/Lucene and > Elasticsearch will no longer work with Java 9 unless you require users to add > those strange options.

Re: Java module graph png settings?

Hi Mandy, Can you tell me what options with the Graphviz framework are to get the actual PNG file out of the jdk.dot file? I tried to find this, but did not find the actual place. -Patrick > Am 08.12.2016 um 07:18 schrieb Mandy Chung : > > Hi Patrick > > Are you

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, Thanks for the hints to fix Groovy, although this is hard to do with ANT (which is our build system). The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, but it does not solve the underlying issue. Apache Solr/Lucene and Elasticsearch will no longer work with

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

A related problem is that opening these packages to satisfy gradle/grooy can mask other non-gradle problems with the same packages. I isolated these options in our shell that invokes Gradle, although that still isn't perfect since we run lots of Java programs during the build. -Original

Re: Java module graph png settings?

dot -Tpng Mandy > On Dec 9, 2016, at 4:58 PM, Patrick Reinhart wrote: > > Hi Mandy, > > Can you tell me what options with the Graphviz framework are to get the > actual PNG file out of the jdk.dot file? I tried to find this, but did not > find the actual place. > >

hg: jigsaw/jake/jdk: Updates for #VersionedDependences

Changeset: 6743bd89af1f Author:alanb Date: 2016-12-10 05:22 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6743bd89af1f Updates for #VersionedDependences DEBUG_ADD_OPENS for debugging Misc. cleanups !

hg: jigsaw/jake/langtools: Updates for #VersionedDependences

Changeset: 91ebc06d4220 Author:alanb Date: 2016-12-10 05:20 + URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/91ebc06d4220 Updates for #VersionedDependences Contributed-by: jonathan.gibb...@oracle.com, jan.lah...@oracle.com !

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I second the recommendation of using "-Dsun.reflect.debugModuleAccessChecks=true". We use gradle to build JavaFX and I ended up needing the following to allow our build to run with jdk-9+148: export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

Hi, Thanks for your review. Comments below.. On 10/12/16, 2:18 AM, Mandy Chung wrote: On Dec 9, 2016, at 12:49 AM, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8168925/webrev.01/index.html for

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09/12/2016 23:06, Stephen Felts wrote: I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

On 09/12/2016 22:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

Erik, Magnus, I have made the change per your suggestion: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169925/webrev.01/ Jeannette, Jeff, and I went through all .md files and I think asm.md is the only one got the characters messed up. These files are contributed by Jeannette. Also,

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Unsafe is visible in JDK9. See the list at http://openjdk.java.net/jeps/260 I agree that requiring command line options is a problem. The experts don't want to merge module access into the security manager. The link above says "Suggested additions to this list, justified by real-world use

RFR 8168925: MODULES property should be topologically ordered and space-separated list

Please review http://cr.openjdk.java.net/~sundar/8168925/webrev.01/index.html for https://bugs.openjdk.java.net/browse/JDK-8168925 PS. Mandy Chung wrote ModuleSorter for another fix (yet to be pushed). I'm using it for this fix after discussion with her (private email). Thanks, -Sundar

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

On 08/12/2016 14:41, Remi Forax wrote: Chris, this patch is rather ugly. Patching the ModuleDescriptor is not a good idea, maybe it's means that we need a system of metadata associated with a ModuleDescriptor, the hash of a module (which is not part of the module spec but the OpenJDK

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

+1 > On Dec 9, 2016, at 4:49 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8168925/webrev.01/index.html > for https://bugs.openjdk.java.net/browse/JDK-8168925 > > PS. Mandy Chung wrote ModuleSorter for

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

Thanks Alan, so I withdraw my snarky comment. Rémi On December 9, 2016 12:25:19 PM GMT+01:00, Alan Bateman wrote: >On 08/12/2016 14:41, Remi Forax wrote: > >> Chris, >> this patch is rather ugly. >> Patching the ModuleDescriptor is not a good idea, maybe it's means

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

On 09/12/2016 14:09, Remi Forax wrote: Thanks Alan, so I withdraw my snarky comment. Not a problem. There is cleanup to be done in several areas, this is one. For the short term then we need to get the implementation aligned with the proposals in the JSR and then get the cleanup done before

Re: RFR [9] 8170859 : Run time and tool support for ModuleResolution

I'll work with Alan to get these changes re-based on top of the refactoring in jake. Consider this review request withdrawn. -Chris. On 09/12/16 14:09, Remi Forax wrote: Thanks Alan, so I withdraw my snarky comment. Rémi On December 9, 2016 12:25:19 PM GMT+01:00, Alan Bateman

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

> On Dec 9, 2016, at 12:49 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8168925/webrev.01/index.html > for https://bugs.openjdk.java.net/browse/JDK-8168925 > Is the order of Plugin.Category enums