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@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. >
