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

Stephen Felts stephen.felts at oracle.com
Fri Dec 9 23:51:47 UTC 2016


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 Message-----
From: Kevin Rushforth 
Sent: Friday, December 09, 2016 6:33 PM
To: Stephen Felts
Cc: Uwe Schindler; jigsaw-dev at openjdk.java.net; Core-Libs-Dev
Subject: 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
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.lang.invoke=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.base/java.text=ALL-UNNAMED"

-- Kevin


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 handling the exception from setAccessible, so there can be noise.
>   


More information about the core-libs-dev mailing list