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

[Uwe Schindler]

Hi,

will there be an update for JEP 260, so this is documented?

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Friday, December 16, 2016 6:39 PM
> To: Peter Levart <peter.levart at gmail.com>; Core-Libs-Dev <core-libs-
> dev at openjdk.java.net>; jigsaw-dev <jigsaw-dev at openjdk.java.net>; Uwe
> Schindler <uschindler at apache.org>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
> 
> Pushed to jdk9/dev. Should make b150.
> 
>   https://bugs.openjdk.java.net/browse/JDK-8171377
> 
> -Chris.
> 
> > On 14 Dec 2016, at 11:58, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
> >
> > Webrev updated in-place.
> >  http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> >
> > -Chris.
> >
> > On 13/12/16 21:18, Peter Levart wrote:
> >> I think this is OK.
> >>
> >> Just a couple of nits in test:
> >>
> >> 1. You create a static Path bob = Paths.get("bob") field, but then you
> >> don't use it in:
> >>
> >>  56         try (FileChannel fc = FileChannel.open(Paths.get("bob"),
> >> CREATE, WRITE)) {
> >>
> >> 2. badBuffers could include a duplicate and a slice of a direct buffer
> >> allocated with ByteBuffer.allocateDirect()
> >>
> >> 3. The comment in the test is referencing the old method name:
> >>
> >>  26  * @summary Basic test for Unsafe::deallocate
> >>
> >>
> >> Regards, Peter
> >>
> >> On 12/13/2016 08:47 PM, Chris Hegarty wrote:
> >>> Taking into account the feedback so far, and changing the method name
> ( since
> >>> it is an attractive nuisance ), here is where I think we ended up.
> >>>
> >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
> >>>
> >>> If this is agreeable, I’ll file an issue in JIRA to track the code changes, and
> >>> update JEP 260.
> >>>
> >>> -Chris.
> >>