Re: Running jaotc with an external Graal

Can i say again that when using --patch-module, module-info.class should be merged instead of having a warning ? Rémi - Mail original - > De: "Mandy Chung" > À: "Christian Thalinger" > Cc: jigsaw-dev@openjdk.java.net, "hotspot compiler"

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

On 2017-02-15 22:08, Mandy Chung wrote: On Feb 15, 2017, at 12:27 PM, Daniel Fuchs wrote: Hi Mandy, Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ Looks good. I haven't reviewed the build changes. I assume they're OK if you

Re: Running jaotc with an external Graal

> On Feb 15, 2017, at 1:56 PM, 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

Re: Running jaotc with an external Graal

> 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 --patch-module should work. > > Aha! Thanks, Does it?

Re: Running jaotc with an external Graal

I don’t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don’t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the

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

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 other thread does *not* get the object via a call to the

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

> On Feb 15, 2017, at 1:08 PM, Mandy Chung wrote: >> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ You may be interested in the module graphs generated from this change.

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

> On Feb 15, 2017, at 12:27 PM, Daniel Fuchs wrote: > > Hi Mandy, > > > Updated webrev: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ > > Looks good. I haven't reviewed the build changes. > I assume they're OK if you managed to build ;-)

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

Hi Claes, Reading the https://bugs.openjdk.java.net/browse/JDK-8174817 and then the change that was just pushed, I can't seem to figure out what was the problem with original code. I can't find evidence for claims in https://bugs.openjdk.java.net/browse/JDK-8175010 . Is the problem

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

Hi Mandy, > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173374/webrev.01/ Looks good. I haven't reviewed the build changes. I assume they're OK if you managed to build ;-) best regards, -- daniel On 15/02/17 19:32, Mandy Chung wrote: On Feb 15, 2017, at 10:29 AM,

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

> On Feb 15, 2017, at 10:29 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Some early comments: > > GenGraphs.java > -- > > 58 dir = Paths.get(args[++i]); > > may produced ArrayOutOfBoundsException - should we have better > error reporting? >

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

> 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 perform worse in certain ways, mostly >

Re: Review Request: JDK-8173374: Update GenGraphs tool to generate dot graph with requires transitive edges

Hi Mandy, Some early comments: GenGraphs.java -- 58 dir = Paths.get(args[++i]); may produced ArrayOutOfBoundsException - should we have better error reporting? Or should it check && i < args.length - 1 so that it falls back to having dir == null below? 93

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

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, there's a strong assumption in

Re: Extending java.base module

On Wed, Feb 15, 2017 at 5:16 PM, Alan Bateman wrote: > On 15/02/2017 16:01, Daniel Fuchs wrote: > >> >> In that specific case it's not java.base that depends >> on java.security.jgss, but the application itself. >> >> So I would expect the application code to either

Re: Extending java.base module

On 15/02/2017 16:01, Daniel Fuchs wrote: In that specific case it's not java.base that depends on java.security.jgss, but the application itself. So I would expect the application code to either require java.security.jgss, or some higher level module for that itself requires

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

> On Feb 15, 2017, at 5:22 AM, 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 ImageReader > lazy

Re: Extending java.base module

Hi Volker, On 15/02/17 15:52, Volker Simonis wrote: Hi Max, I'm not an jigsaw either, but wouldn't your solution break a tool like jlink? In other words, if an application uses your code and the developer uses jlink to create a run-time image, wouldn't that image fail to execute his

Re: Extending java.base module

Hi Max, I'm not an jigsaw either, but wouldn't your solution break a tool like jlink? In other words, if an application uses your code and the developer uses jlink to create a run-time image, wouldn't that image fail to execute his application because jlink fails to see that java.base depends on

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

Jim, Chris, Alan, thanks for reviewing! On 02/15/2017 02:56 PM, Alan Bateman wrote: On 15/02/2017 13:22, 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

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

On 15/02/2017 13:22, 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 ImageReader lazy there appears to be cases where ImageReaders are not

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

On 02/14/2017 05:52 PM, mark.reinh...@oracle.com wrote: 2017/2/13 9:17:47 -0800, Guillaume Smet : On Mon, Feb 13, 2017 at 6:10 PM, alan.bate...@oracle.com wrote: On 13/02/2017 16:58, Guillaume Smet wrote: On Mon, Feb 13, 2017 at 5:12 PM, alan.bate...@oracle.com wrote:

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

> On 15 Feb 2017, at 13:22, 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 ImageReader > lazy there

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

+1 > On Feb 15, 2017, at 9:22 AM, 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 ImageReader > lazy

Re: Extending java.base module

> > E.g. if I need to register/reach my service already at the early stages of > JVM initialization, e.g. when a class java.lang.Thread gets initialized, > can I assume a service from my extension module would be available? > No. At that time only java.base classes can be loaded. If you look at

Re: Extending java.base module

On 15/02/2017 12:10, David Holmes wrote: On 15/02/2017 8:03 PM, Langer, Christoph wrote: Hi Chris, Max, thanks for your quick answers. So the service approach seems to fit quite well. But can I assume that my service implementation will be available already at "bootstrap time" of the

Re: Extending java.base module

On 15/02/2017 8:03 PM, Langer, Christoph wrote: Hi Chris, Max, thanks for your quick answers. So the service approach seems to fit quite well. But can I assume that my service implementation will be available already at "bootstrap time" of the JDK? E.g. if I need to register/reach my service

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

I agree. Remi On February 15, 2017 12:52:53 AM GMT+01:00, mark.reinh...@oracle.com wrote: >2017/2/13 9:17:47 -0800, Guillaume Smet : >> On Mon, Feb 13, 2017 at 6:10 PM, alan.bate...@oracle.com wrote: >>> On 13/02/2017 16:58, Guillaume Smet wrote: On Mon, Feb 13,

Re: Extending java.base module

On 15/02/2017 08:36, Langer, Christoph wrote: Hi Jigsaw experts, as you might or might not know, we have an own JDK implementation with some extension code that is quite interwoven with the jdk. Now I'm looking into how this coding can be spread into a good module structure for jdk9. And

RE: Extending java.base module

Hi Chris, Max, thanks for your quick answers. So the service approach seems to fit quite well. But can I assume that my service implementation will be available already at "bootstrap time" of the JDK? E.g. if I need to register/reach my service already at the early stages of JVM

Re: Extending java.base module

> On 15 Feb 2017, at 08:51, Weijun Wang wrote: > > Disclaimer: I am not a jigsaw expert. > > The provides/uses mechanism is certainly more formal, but you can also do > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. This is, at best, a hack. The use of

Re: Extending java.base module

Disclaimer: I am not a jigsaw expert. The provides/uses mechanism is certainly more formal, but you can also do http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b. --Max On 02/15/2017 04:36 PM, Langer, Christoph wrote: Hi Jigsaw experts, as you might or might not know, we have an own

Extending java.base module

Hi Jigsaw experts, as you might or might not know, we have an own JDK implementation with some extension code that is quite interwoven with the jdk. Now I'm looking into how this coding can be spread into a good module structure for jdk9. And I'm not a crack yet on using the module system