Re: Module exports for java.base: NIO stuff

On 11/12/2016 22:38, David M. Lloyd wrote: I'm not implementing SelectorProvider, I just want access to all the possible implementations that are available in the current JDK so we can select among them on a case-by-case basis. Are you attempting to wrap the default implementation - I ask

Re: Use cases for java.lang.Module.addExports

On 12/12/2016 06:34, David Holmes wrote: Does addExports only affect reflective access to the module, or does it change all access? I'm trying to determine what the set of actions X will be such that: try { ; } catch () { execute( () -> mod.addExports(...)); // address the problem ;

Use cases for java.lang.Module.addExports

Does addExports only affect reflective access to the module, or does it change all access? I'm trying to determine what the set of actions X will be such that: try { ; } catch () { execute( () -> mod.addExports(...)); // address the problem ; // now it succeeds } Thanks, David

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

Hi Mandy, I'll refactor (and revisit) TOP/OTHER types in my next jlink change. Thanks for the review. Thanks, -Sundar On 12/12/16, 11:04 AM, Mandy Chung wrote: On Dec 11, 2016, at 9:30 PM, Sundararajan Athijegannathan wrote: Hi, Please review

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

> On Dec 11, 2016, at 9:30 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8168925/webrev.02/ This looks better. Thanks for making the change. One thing to mention is that

Re: RFR 8168925: MODULES property should be topologically ordered and space-separated list

Hi, Please review the updated webrev: http://cr.openjdk.java.net/~sundar/8168925/webrev.02/ Changes from the last review: * Moved all release file property filling code from DefaultImageBuilder.java to ReleaseInfoPlugin.java * DefaultImageBuilder populates this.targetOsName directly from

Re: Proposal: #VersionedDependences

On 9 December 2016 at 21:46, wrote: > When compiling a module that depends on some other modules, record the > version strings of those modules, if available, in the resulting module > descriptor. Overall this seems like a good idea, for diagnostic reasons. > Now that

Re: Module exports for java.base: NIO stuff

On 12/11/2016 05:18 AM, Alan Bateman wrote: On 10/12/2016 15:21, David M. Lloyd wrote: 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:

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

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

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

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

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

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)

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

Hi Uwe, On 12/11/2016 01:57 PM, Uwe Schindler wrote: Hi, How about the following: -Check that the buffer is direct, if not throw IAE(“not direct buffer”) -Check that buffer has attachment==null (this tells you that it’s not a slice/dup), if not throw IAE(“not allowed to free

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

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

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

The parts of this which I know about (the client licenses) look fine to me. Some day we should look at whether we still have vestiges of X11 in the Mac code from the BSD port but for now its safer to assume there are .. By this I mean "unix" includes Mac. as a core OS, but not as a desktop

Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

On 23.11.2016 12:55, Alan Bateman wrote: > > We've been accumulating changes in the jake forest that are tied to JSR > issues for the last few > months. Some of the changes (such as #ClassLoaderNames) have already been > pushed upstream to > jdk9/dev but we've still sitting on a large patch. > >

Re: Module exports for java.base: NIO stuff

On 11/12/2016 11:44, Remi Forax wrote: : No, these are different implementation, they directly use classes from sun.nio.ch and bypass the selector API. Sure, but the SelectorProvider service interface doesn't define anything that allows someone to choose when there are multiple

Re: Sync with jdk9 and ASM alpha 2

On 11/12/2016 13:05, Remi Forax wrote: Hi Alan, if i get it right, the jdk9 b148 (not the jigsaw version) get a refresh of module-info classfile format but did not get the last two changes, version of requires and the two new constant pool entries. Do you plan to push these changes in the jdk9

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

Hi, How about the following: - Check that the buffer is direct, if not throw IAE(“not direct buffer”) - Check that buffer has attachment==null (this tells you that it’s not a slice/dup), if not throw IAE(“not allowed to free duplicates/slices”) - Finally do the

Re: Module exports for java.base: NIO stuff

- Mail original - > De: "Alan Bateman" > À: "David M. Lloyd" , "jigsaw-dev" > > Envoyé: Dimanche 11 Décembre 2016 12:18:26 > Objet: Re: Module exports for java.base: NIO stuff > On 10/12/2016 15:21, David M.

Re: jlink and automatic modules

On 10/12/2016 22:40, Claes Redestad wrote: The intended behavior is for jlink to operate on any set of modules to support linking images for other platforms, operating systems etc (the java.base jmod shipped with any JDK contains a native JVM), so it may feel more natural to make it explicit

Re: Module exports for java.base: NIO stuff

On 10/12/2016 15:21, David M. Lloyd wrote: 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

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

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

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

> 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