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

[Alan Bateman]

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

-Alan