Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
Alan.Bateman at oracle.com
Sat Dec 10 05:14:13 UTC 2016
On 09/12/2016 22:32, Uwe Schindler wrote:
> 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 as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge
sun.misc.Cleaner was indeed on the original list of APIs for JEP 260 to
identify as a "critical internal API". It turned out not to be useful
because it would have required some way to get the Cleaner in the first
place. That lead to the "new" hack that is reading the private "cleaner"
field from DBB and treating it as a Runnable. That hack now breaks
because setAccessible has changed in jdk-9+148 to align with the JSR 376
proposal tracked as #AwkwardStrongEncapsulation.
No need to panic though, there is an update to JEP 260 coming soon for
this specific need. Details TDB but it will probably be a method in
jdk.unsupported module. It does mean that libraries using the old (or
"new") hacks will need to change. I hope it will be seen as a reasonable
compromise for this generally awkward issue.
More information about the core-libs-dev