Re: How to name modules, automatic and otherwise

On 02/17/2017 12:19 AM, Stephen Colebourne wrote: The simplest and most consistent option is reverse DNS everywhere. Everyone understand it and few will object! An alternative option would be that open source can use short names, but companies "must" use reverse DNS. But this is far from ideal

Re: How to name modules, automatic and otherwise

On 16 February 2017 at 16:48, wrote: > This can be done very simply, with a single new JAR-file manifest > `Module-Name` attribute I welcome this. > The reversed domain-name approach was sensible in the early days of Java, > before we had development tools

Re: Performance of JrtFileSystemProvider.exists

Thanks, Alan. Good to hear that this is on the radar. In the meantime, I think I can solve our performance problem by using the /packages namespace to route lookups to the relevant module(s) to avoid so many negative lookups in the first place. Regards, Jason On Thu, 16 Feb 2017 at 18:44

Re: RFR: 8175026: Capture build-time parameters to --generate-jli-classes

One more thing: the warning message should be in plugin.properties to be localized. Mandy > On Feb 16, 2017, at 12:04 PM, Mandy Chung wrote: > > >> On Feb 16, 2017, at 5:20 AM, Claes Redestad >> wrote: >> >>> >>> In addition, if the main

Re: RFR: 8175026: Capture build-time parameters to --generate-jli-classes

> On Feb 16, 2017, at 5:20 AM, Claes Redestad wrote: > >> >> In addition, if the main argument is specified but the version does not >> match, it will ignore the given argument. Should it be an error instead? >> We are the one who will generate a trace file and

Re: How to name modules, automatic and otherwise

Hello, This looks reasonable. Is it going to be implemented in JDK9 prior GA date? Martin On 16.2.2017 17:48, mark.reinh...@oracle.com wrote: Thanks to everyone for all the feedback on this topic. I've posted my conclusions here:

hg: jigsaw/jake: 2 new changesets

Changeset: 72761323ba0a Author:lana Date: 2017-02-16 17:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/rev/72761323ba0a Added tag jdk-9+157 for changeset 4eb77fb98952 ! .hgtags Changeset: d3c64c12b7c0 Author:alanb Date: 2017-02-16 18:00 + URL:

hg: jigsaw/jake/jdk: 4 new changesets

Changeset: 96748d4b1204 Author:jlahoda Date: 2017-02-13 09:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96748d4b1204 8173777: Merge javac -Xmodule into javac--patch-module Summary: Converting uses of -Xmodule: to --patch-module. Reviewed-by: alanb, mchung -

hg: jigsaw/jake/hotspot: 2 new changesets

Changeset: 4e78f3093522 Author:lana Date: 2017-02-16 17:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4e78f3093522 Added tag jdk-9+157 for changeset b2d0a906afd7 ! .hgtags Changeset: f06b24e86ca5 Author:alanb Date: 2017-02-16 18:10 + URL:

hg: jigsaw/jake/nashorn: 2 new changesets

Changeset: 13ae2480a4c3 Author:lana Date: 2017-02-16 17:13 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/13ae2480a4c3 Added tag jdk-9+157 for changeset f6070efba6af ! .hgtags Changeset: a71b174558de Author:alanb Date: 2017-02-16 18:02 + URL:

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 2dbdf7460052 Author:lana Date: 2017-02-16 17:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2dbdf7460052 Added tag jdk-9+157 for changeset b7e70e1e0154 ! .hgtags Changeset: 2caee4d0ea4f Author:alanb Date: 2017-02-16 18:03 + URL:

hg: jigsaw/jake/langtools: 4 new changesets

Changeset: 8be741555fa6 Author:jlahoda Date: 2017-02-13 09:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8be741555fa6 8173777: Merge javac -Xmodule into javac--patch-module Summary: Merging -Xmodule: functionality into --patch-module. Reviewed-by: jjg, mchung,

hg: jigsaw/jake/jaxp: 2 new changesets

Changeset: 80143dad68ba Author:lana Date: 2017-02-16 17:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/80143dad68ba Added tag jdk-9+157 for changeset 412df235a8a2 ! .hgtags Changeset: 78a99c5871b1 Author:alanb Date: 2017-02-16 18:02 + URL:

hg: jigsaw/jake/corba: 2 new changesets

Changeset: de6bdf38935f Author:lana Date: 2017-02-16 17:12 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/de6bdf38935f Added tag jdk-9+157 for changeset 9383da04b385 ! .hgtags Changeset: a3f338a105fa Author:alanb Date: 2017-02-16 18:02 + URL:

Re: How to name modules, automatic and otherwise

Thanks for the follow up Mark. I obviously don't completely agree with all of the assumptions and that's ok. I do however applaud the inclusion of the Module-Name into the algorithm. This gives enough of a hook that tools like Maven can hopefully send the ecosystem down a smooth transition path,

How to name modules, automatic and otherwise

Thanks to everyone for all the feedback on this topic. I've posted my conclusions here: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html - Mark

Re: RFR: 8175079: Lazy initialization of ImageReader breaks rmid

Done! On 02/16/2017 05:27 PM, Alan Bateman wrote: I think go with the first for now. -Alan On 16/02/2017 16:24, Claes Redestad wrote: Hi, please review this simple backout of a startup optimization that has proven to destabilize things like rmid. Patch inline.. Bug:

Re: Running jaotc with an external Graal

> On Feb 16, 2017, at 1:33 AM, Doug Simon wrote: > > With the current bits in jdk9/hs and graal-core, the following bootstrapping > command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions >

Re: RFR: 8175026: Capture build-time parameters to --generate-jli-classes

Hi Mandy, On 02/15/2017 08:09 PM, Mandy Chung wrote: On Feb 15, 2017, at 9:12 AM, Claes Redestad wrote: Hi, currently the file we generate at build time as input to --generate-jli-classes is lost when linking custom images, which means user generate images may

Re: Running jaotc with an external Graal

With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar

Re: Running jaotc with an external Graal

On 15/02/17 21:56, Christian Thalinger wrote: > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then

Re: RFR: 8175010: ImageReader is not thread-safe

Hi David, On 2017-02-16 09:08, David Holmes wrote: Hi Claes, On 15/02/2017 11:22 PM, Claes Redestad wrote: Hi, a few intermittent but rare test failures[1] that has appeared since the latest jake integration, and since one of the changes in there was to make initialization of the system

Re: RFR: 8175010: ImageReader is not thread-safe

On 2017-02-16 09:17, Peter Levart wrote: I think your observations about potential issues in JRTFS is correct, but there was nothing to suggest JRTFS code was involved in JDK-8174817 (as it's not code that's used by the BuiltinClassLoader). The only remaining ImageReader.close() invocation

Re: Performance of JrtFileSystemProvider.exists

On 16/02/2017 08:15, Jason Zaugg wrote: Recently I modified the Scala compiler to read class files jrt:/ filesystem, rather than relying on rt.jar. I noticed a slowdown when running on JDK 9 ea and exercising this code. Profiles suggest that the bottleneck is in calls to Files.exists.

Re: RFR: 8175010: ImageReader is not thread-safe

Hi Claes, On 02/15/2017 10:41 PM, Claes Redestad wrote: Hi Peter, are you suggesting that if I have class Foo { Bar b; }, then creating and putting Foo b in a CHM before returning it to a consumer which is then read from another thread is enough to force b to be safely published even when the

Performance of JrtFileSystemProvider.exists

Recently I modified the Scala compiler to read class files jrt:/ filesystem, rather than relying on rt.jar. I noticed a slowdown when running on JDK 9 ea and exercising this code. Profiles suggest that the bottleneck is in calls to Files.exists. JrtFileSystemProvider inherits an implementation

Re: RFR: 8175026: Capture build-time parameters to --generate-jli-classes

On 2017-02-15 18:12, Claes Redestad wrote: Hi, currently the file we generate at build time as input to --generate-jli-classes is lost when linking custom images, which means user generate images may perform worse in certain ways, mostly generating more classes during startup. Additionally,