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

[Peter Levart]

Hi,


On 12/10/2016 06:14 AM, Alan Bateman wrote:
> 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

Something like the following?

http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/


Regards, Peter