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 cases and estimates of developer and end-user impact, are welcome". So you should make clear exactly API's that you want exposed. -----Original Message----- From: Uwe Schindler [mailto:uschind...@apache.org] Sent: Friday, December 09, 2016 6:22 PM To: Stephen Felts; jigsaw-dev@openjdk.java.net; Core-Libs-Dev Subject: 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 Java 9 unless you require users to add those strange options. Elasticsearch already runs with a SecurityManager by default, so the question is: why is this not handled by a security manager and a new permission like "crossModuleAccess/module/package"? Why must it be done on command line? This makes it impossible to ship something like Lucene that it work out of box together with correct policy files? And as said in my previous mail: The direct bytebuffer unmapping has still no "official" way to do it, but it is critical to large scale database systems like Lucene/Solr/Elasticsearch. You have replacements in Java 9 for Unsafe (VarHandles,...), but still no way to allow unmapping of byte buffers that sit on huge resources or disallow deleting of files on windows. It was discussed on last FOSDEM to do something in Java 10 (I would like to get information how to propose the required change as Java 10 dev started now!), and in the meantime it was confirmed that some APIs in the JDK are "critical" and will be supported. But this is now So please re-add the special critical APIs back to the whitelist, so code like getting (legacy) Unsafe or unmapping direct buffers works without command line parameters that confuse people. Uwe ----- Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Stephen Felts [mailto:stephen.fe...@oracle.com] > Sent: Saturday, December 10, 2016 12:07 AM > To: Uwe Schindler <uschind...@apache.org>; > jigsaw-dev@openjdk.java.net; Core-Libs-Dev > <core-libs-...@openjdk.java.net> > Subject: 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 there can be noise.
