che.org; jigsaw-...@openjdk.java.net; 'Core-Libs-Dev'
> <core-libs-dev@openjdk.java.net>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> Hi,
>
> I strongly hope Paul and Cedric will be able to start the release
> process next week, if
bs-Dev > d...@openjdk.java.net>; jigsaw-dev <jigsaw-...@openjdk.java.net>; Uwe
>> Schindler <uschind...@apache.org>
>> Subject: Re: Java 9 build 148 causes trouble in Apache
>> Lucene/Solr/Elasticsearch
>>
>> Pushed to jdk9/dev. Should make b150.
>&
t: Friday, December 16, 2016 6:39 PM
> To: Peter Levart <peter.lev...@gmail.com>; Core-Libs-Dev d...@openjdk.java.net>; jigsaw-dev <jigsaw-...@openjdk.java.net>; Uwe
> Schindler <uschind...@apache.org>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Luc
hindler <uschind...@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
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 wrote:
>
> Webrev updated in-place.
> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>
> -Chris.
>
> On 13/12/16
: Jochen Theodorou [mailto:blackd...@gmx.org]
Sent: Saturday, December 10, 2016 9:23 AM
To: Uwe Schindler <uschind...@apache.org>; jigsaw-...@openjdk.java.net;
Core-Libs-Dev <core-libs-dev@openjdk.java.net>
Subject: Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
O
0, 2016 9:23 AM
> To: Uwe Schindler <uschind...@apache.org>; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev <core-libs-dev@openjdk.java.net>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> On 09.12.2016 23:32, Uwe Schindler wrote
On 13/12/2016 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)) {
Adding to Peter's
ore-Libs-Dev d...@openjdk.java.net>; jigsaw-dev <jigsaw-...@openjdk.java.net>; Uwe
> Schindler <uschind...@apache.org>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> Webrev updated in-place.
>http://cr.openjdk.java.net/~ch
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
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
acle.com]
> Sent: Tuesday, December 13, 2016 8:47 PM
> To: Core-Libs-Dev <core-libs-dev@openjdk.java.net>; jigsaw-dev d...@openjdk.java.net>; Uwe Schindler <uschind...@apache.org>; Peter
> Levart <peter.lev...@gmail.com>
> Subject: Re: Java 9 build 148 cau
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
On 12/9/16 3:21 PM, Uwe Schindler wrote:
> The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed,
> but it does not solve the underlying issue. Apache Solr/Lucene and
> Elasticsearch will no longer work with Java 9 unless you require users to add
> those strange options.
Dear Alan,
On Sun, Dec 11, 2016 at 6:16 AM, Alan Bateman
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
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
Hi Alan,
On 12/11/2016 12:16 PM, Alan Bateman wrote:
On 10/12/2016 17:11, Chris Hegarty wrote:
:
How about: Unsafe::deallocate(ByteBuffer directBuffer)?
http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
The alternative is of course:
ByteBuffer wrap(long address, int capacity)
org>; Chris Hegarty
<chris.hega...@oracle.com>
*Cc:* jigsaw-...@openjdk.java.net; Core-Libs-Dev
<core-libs-dev@openjdk.java.net>
*Subject:* Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
On 12/10/2016 09:00 PM, Uwe Schindler wrote:
Hi,
We no
Hi Chris,
On 12/11/2016 10:26 AM, Chris Hegarty wrote:
>"Deallocates the underlying memory associated with given directBuffer if the
buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link
FileChannel#map} methods. In any other case (when the buffer is not a direct buffer
jdk.java.net; Core-Libs-Dev <core-libs-dev@openjdk.java.net>
Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
On 12/10/2016 09:00 PM, Uwe Schindler wrote:
Hi,
We noticed that buffers with zero length also have no cleaner. This is why we
also have the
On 10/12/2016 17:11, Chris Hegarty wrote:
:
How about: Unsafe::deallocate(ByteBuffer directBuffer)?
http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
The alternative is of course:
ByteBuffer wrap(long address, int capacity)
void unmap(MappedByteBuffer)
The wrap method allow be
> On 10 Dec 2016, at 19:47, Peter Levart wrote:
>
> Hi Chris,
>
> On 12/10/2016 06:11 PM, Chris Hegarty wrote:
>> How about: Unsafe::deallocate(ByteBuffer directBuffer)?
>>
>> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
>
> Apart from the fact that Unsafe
On 12/10/2016 09:00 PM, Uwe Schindler wrote:
Hi,
We noticed that buffers with zero length also have no cleaner. This is
why we also have the null check in our code (see Github) and the
guardWithTest in the MethodHandle, although we never free duplicates.
So a noop is better imho.
Oh yes,
Hi,
We noticed that buffers with zero length also have no cleaner. This is why we
also have the null check in our code (see Github) and the guardWithTest in the
MethodHandle, although we never free duplicates. So a noop is better imho.
I like the Unsafe approach. To me both variants are fine.
Hi Chris,
On 12/10/2016 06:11 PM, Chris Hegarty wrote:
How about: Unsafe::deallocate(ByteBuffer directBuffer)?
http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
Apart from the fact that Unsafe is (was?) reserved for low-level stuff,
I think this approach is reasonable. Is the method
l from Oracle to see what they have in mind...
>
> Regards, Peter
>
>> Uwe
>>
>> -
>>
>> Uwe Schindler
>>
>> uschind...@apache.org
>>
>> ASF Member, Apache Lucene PMC / Committer
>>
>> Bremen, Germany
>>
>>
et>
*Subject:* Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
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. Pre
:10 PM
To: Alan Bateman <alan.bate...@oracle.com>; Uwe Schindler
<uschind...@apache.org>; jigsaw-...@openjdk.java.net; Core-Libs-Dev
<core-libs-dev@openjdk.java.net>
Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
Hi,
On 12/10/2016 06:1
On 10/12/2016 08:22, Jochen Theodorou wrote:
:
A fix for this is already committed, we are only waiting for release
of Groovy 2.4.8. Of course even with the fix Groovy code can possibly
break... for example if you did the direct buffer access in Groovy.
Thanks for sharing, that is very
On 10/12/2016 11:09, Peter Levart wrote:
:
Something like the following?
http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/
Sort of although I think the proposal will be more specific, as in
unmap(MappedByteBuffer) on an existing class.
The other update to JEP
6 6:14 AM
> To: Uwe Schindler <uschind...@apache.org>; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev <core-libs-dev@openjdk.java.net>
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> On 09/12/2016 22:32, Uwe Schindler wrote:
>
>
On 09.12.2016 23: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
On 09/12/2016 23:06, Stephen Felts wrote:
I would highly recommend running with
_JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true
It will tell you what add-options are required.
One minor downside is that it will produce the warning in cases where the
software is already correctly
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
k.java.net; Core-Libs-Dev
Subject: RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
Hi,
Thanks for the hints to fix Groovy, although this is hard to do with ANT (which
is our build system).
The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed,
b
I second the recommendation of using
"-Dsun.reflect.debugModuleAccessChecks=true". We use gradle to build
JavaFX and I ended up needing the following to allow our build to run
with jdk-9+148:
export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true
e.com]
> Sent: Saturday, December 10, 2016 12:07 AM
> To: Uwe Schindler <uschind...@apache.org>; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev <core-libs-dev@openjdk.java.net>
> Subject: RE: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elastic
I would highly recommend running with
_JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true
It will tell you what add-options are required.
One minor downside is that it will produce the warning in cases where the
software is already correctly handling the exception from setAccessible, so
38 matches
Mail list logo