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

[Peter Levart]

On 12/11/2016 09:59 PM, Peter Levart wrote:
>> The alternative is of course:
>>
>> ByteBuffer wrap(long address, int capacity)
>> void unmap(MappedByteBuffer)
>>
>> The wrap method allow be similar to JNI's NewDirectByteBuffer for 
>> those that are managing the underlying memory themselves. This makes 
>> it a more advanced method to avoid too much temptation to free the 
>> memory underlying a buffer created with ByteBuffer.allocateDirect. We 
>> can't do much with unmap but that at least won't be widely used.
>>
>> -Alan.
>
> So, If I understand correctly, you are proposing users to do their own 
> memory allocation/management/deallocation with Unsafe and use wrap() 
> just to create a view of the allocated memory in the form of 
> ByteBuffer. Wouldn't this force them to use a different approach to 
> managing ByteBuffer(s) from what they do now - they would have to keep 
> the allocated memory's address somewhere outside the buffer in order 
> to free the memory later... It is doable, but I think Uwe will not 
> like it very much.

Sorry, I just realized that Uwe is interested only in the unmapping case...

>
> About unmap()... Is it just the name and signature that would 
> discourage freeing memory underlying a buffer created with 
> ByteBuffer.allocateDirect() or do you propose to disallow such use and 
> only allow actual unmapping?