d...@groovy.apache.org; jigsaw-...@openjdk.java.net; 'Core-Libs-Dev'
>
> 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 not we will have t
ommitter
> Bremen, Germany
> http://lucene.apache.org/
>
>> -Original Message-
>> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
>> Sent: Friday, December 16, 2016 6:39 PM
>> To: Peter Levart ; Core-Libs-Dev > d...@openjdk.java.net>; jigsaw-dev ; Uwe
>>
t: Friday, December 16, 2016 6:39 PM
> To: Peter Levart ; Core-Libs-Dev d...@openjdk.java.net>; jigsaw-dev ; Uwe
> Schindler
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> Pushed to jdk9/dev. Should make b150.
>
> http
http://lucene.apache.org/
> -Original Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Friday, December 16, 2016 6:39 PM
> To: Peter Levart ; Core-Libs-Dev d...@openjdk.java.net>; jigsaw-dev ; Uwe
> Schindler
> Subject: Re: Java 9 build 148 causes troub
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 21:18, Peter Levart wrote:
>>
: Jochen Theodorou [mailto:blackd...@gmx.org]
Sent: Saturday, December 10, 2016 9:23 AM
To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
Core-Libs-Dev
Subject: Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
On 09.12.2016 23:32, Uwe Schindler wrote:
Hi,
I updated our Jenkins
0, 2016 9:23 AM
> To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> On 09.12.2016 23:32, Uwe Schindler wrote:
> > Hi,
> >
> > I updated our Jenkins server f
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 c
njdk.java.net>; jigsaw-dev ; Uwe
> Schindler
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> Webrev updated in-place.
>http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/
>
> -Chris.
>
> On 13/12/16 21:18, Peter
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 (File
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
..@oracle.com]
> Sent: Tuesday, December 13, 2016 8:47 PM
> To: Core-Libs-Dev ; jigsaw-dev d...@openjdk.java.net>; Uwe Schindler ; Peter
> Levart
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> Taking into account the feedback so far
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 26
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 managing the underlying memory t
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
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)
void
s Hegarty
*Cc:* jigsaw-...@openjdk.java.net; Core-Libs-Dev
*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
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
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 null check in our code (see Github) and the guardWithTest in the
MethodHandle, although we never
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 simil
> 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 is (was?) reserved for lo
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 i
e what they have in mind...
>
> Regards, Peter
>
>> Uwe
>>
>> -
>>
>> Uwe Schindler
>>
>> uschind...@apache.org
>>
>> ASF Member, Apache Lucene PMC / Committer
>>
>> Bremen, Germany
>>
>> http://lucene.apache
remen, Germany
http://lucene.apache.org/
*From:*Peter Levart [mailto:peter.lev...@gmail.com]
*Sent:* Saturday, December 10, 2016 12:10 PM
*To:* Alan Bateman ; Uwe Schindler
; jigsaw-...@openjdk.java.net; Core-Libs-Dev
*Subject:* Re: Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch
Hi,
On
:10 PM
To: Alan Bateman ; Uwe Schindler
; jigsaw-...@openjdk.java.net; Core-Libs-Dev
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
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 usefu
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 2
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 stu
6 6:14 AM
> To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev
> Subject: Re: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> On 09/12/2016 22:32, Uwe Schindler wrote:
>
> > Hi,
> >
> > I updated our Jenkins server for t
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 l
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 handl
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
ginal Message-
From: Kevin Rushforth
Sent: Friday, December 09, 2016 6:33 PM
To: Stephen Felts
Cc: Uwe Schindler; jigsaw-...@openjdk.java.net; Core-Libs-Dev
Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
I second the recommendation of
...@openjdk.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, inde
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
--add-opens=java.base/java.lang=ALL-
e.com]
> Sent: Saturday, December 10, 2016 12:07 AM
> To: Uwe Schindler ; jigsaw-...@openjdk.java.net;
> Core-Libs-Dev
> Subject: RE: Java 9 build 148 causes trouble in Apache
> Lucene/Solr/Elasticsearch
>
> I would highly recommend running with _JAVA_OPTIONS=-
> Dsun.refl
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
the
Gradle/groovy are known to have problems with the restricted module access of
b148.
You can get around this specific problem by using the environment variable
_JAVA_OPTIONS=--add-opens=java.base/java.lang=ALL-UNNAMED
The packages that you need to open depend on what Java methods your
gra
41 matches
Mail list logo
