Re: jlink and automatic modules

Hi Gunnar, On 2016-12-10 22:50, Gunnar Morling wrote: Hi, I've been experimenting a bit with the new jlink tool and got two questions: * I'm passing a directory with automatic modules via --module-path; this results in Error: module-info.class not found for xyz module Is this expected,

Re: jlink and automatic modules

- Mail original - > De: "Gunnar Morling" > À: "jigsaw-dev" > Envoyé: Samedi 10 Décembre 2016 22:50:36 > Objet: jlink and automatic modules > Hi, > > I've been experimenting a bit with the new jlink tool and got two questions: > > *

jlink and automatic modules

Hi, I've been experimenting a bit with the new jlink tool and got two questions: * I'm passing a directory with automatic modules via --module-path; this results in Error: module-info.class not found for xyz module Is this expected, i.e. can automatic modules not be used with jlink? * I

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 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,

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

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.

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

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

Re: AccessbileObject setAccessible array version vs non-array version

On 10.12.2016 13:08, Alan Bateman wrote: On 10/12/2016 09:13, Jochen Theodorou wrote: Hi all, motivated by the recent "Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch" thead, I thought I ask... there is AcccessibleObject#setAccessible(boolean), which will ask the

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

I think it best to keep whatever we do here simple and straight forward. It is, after all, just a stop gap until a public API can be put in place in a future release ( which I believe is a realistic possibility given some of the discussions that I have heard about, but that is for another day).

Module exports for java.base: NIO stuff

Would it be possible to have all available selector provider implementation classes listed in a "provides java.nio.channels.spi with ..." section of java.base's module descriptor? My use case is as follows: Our I/O library (XNIO) relies on the ability to detect and use different available

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

Hi Uwe, On 12/10/2016 01:33 PM, Uwe Schindler wrote: Hi Peter, this would be a great fix! Thanks!!! I also think the non-static method is superior to my original proposal, because it allows us to do the security check **once**, which is really needed for Lucene. I am still fine if the

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

Hi Peter, this would be a great fix! Thanks!!! I also think the non-static method is superior to my original proposal, because it allows us to do the security check *once*, which is really needed for Lucene. I am still fine if the permission is still checked on every unmapping, but we

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

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

Re: AccessbileObject setAccessible array version vs non-array version

On 10/12/2016 09:13, Jochen Theodorou wrote: Hi all, motivated by the recent "Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch" thead, I thought I ask... there is AcccessibleObject#setAccessible(boolean), which will ask the SecurityManager for permissions and then make

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. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following

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

Thanks Alan, I will look forward to see a solution for this! THANKS! A static method somewhere in jdk.internal to trigger the unmapping of a MappedByteBuffer would be fine. This is easy to change in our code, we just need a MethodHandle to a function with the following signature: static void

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 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

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

Looks good, thanks! /Erik On 2016-12-10 08:54, Mandy Chung wrote: On Dec 9, 2016, at 11:51 PM, Erik Joelsson wrote: Hello Mandy, In Copy-java.base.gmk. Modules.gmk is no longer needed. JMOD_* varaibles are no longer used. Good catch. In Main.gmk, it would be