Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

On 27/10/2016 07:05, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html If -cp is not specified and -m is not specified, the builtin system class loader will default the class path to the current working directory. If -m is specified, no

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 26/10/2016 00:10, Mandy Chung wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/webrev.00/ Specdiff: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/specdiff/overview-summary.html This is a long-standing RFE for adding support for class loader names.

8168789: ModuleReader.list and ModuleFinder.of update

We have a lot changes in the jake forest. I need to bring some of the changes that aren't tied to JSR issues into jdk9/dev to unblock others. Specifically, I'd like to bring over the changes that are needed to allow jlink to support linking of MR JARs. Steve has initial patches (there's a sepa

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

It looks like if you have a class loader name but not a module (i.e. it's unnamed), you get output that looks like this: [...] at org.jboss.as.controller//org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:390) [...] In this case the

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

> On Oct 27, 2016, at 7:30 AM, David M. Lloyd wrote: > > It looks like if you have a class loader name but not a module (i.e. it's > unnamed), you get output that looks like this: > >[...] >at > org.jboss.as.controller//org.jboss.as.controller.AbstractControllerService.boot(Ab

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

On 10/27/2016 09:59 AM, Mandy Chung wrote: On Oct 27, 2016, at 7:30 AM, David M. Lloyd wrote: It looks like if you have a class loader name but not a module (i.e. it's unnamed), you get output that looks like this: [...] at org.jboss.as.controller//org.jboss.as.controller.Abs

New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

Thanks to everyone who commented on the weak-modules proposal. I've just posted a third proposal for #ReflectiveAccessToNonExportedTypes, along with an analysis of the proposals presented thus far: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html http://mail

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On Oct 27, 2016, at 2:44 AM, Alan Bateman wrote: > > The updated comment in ClassLoaders might be a bit clearer if you drop "if > defined”. > OK, dropped “if defined”. > A minor comment on the test is that it could use ProcessTools.executeTestJava > to avoid needing JAVA_TOOL. ProcessToo

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

A somewhat peripheral comment on: > To ensure the integrity of the platform we expect that all the modules of > the JDK itself will be normal modules and that very few, if any, packages > will be opened. I’m wondering if it would be possible to open the package(s) used by Swing Look and Feels, to

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

I find this text much more demonstrative of the needs of the many. Thanks for continuing to work through things with the community and understand needs that we all have for a good path forward which allows everyone to use JDK9 and for the future to hold a much better view of encapsulation witho

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

On 27/10/2016 18:02, Mandy Chung wrote: On Oct 27, 2016, at 2:44 AM, Alan Bateman wrote: The updated comment in ClassLoaders might be a bit clearer if you drop "if defined”. OK, dropped “if defined”. A minor comment on the test is that it could use ProcessTools.executeTestJava to avoid n

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On Oct 27, 2016, at 12:24 PM, Paul Sandoz wrote: > > >> On 26 Oct 2016, at 22:59, Mandy Chung wrote: >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html >> >> If -cp is not specified and -m is not specified, the builtin system >> class loader will

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

Hi, Mandy It looks pretty good to me. Just a couple small things: * StackTraceElement.java 379 ClassLoader loader = cls.getClassLoader0(); It looks as if 'loader' isn't used...? * Throwable.java 832 // VM to fill in StackTraceElement 833 getStackTrace

Re: 8168789: ModuleReader.list and ModuleFinder.of update

> On Oct 27, 2016, at 4:20 AM, Alan Bateman wrote: > > We have a lot changes in the jake forest. I need to bring some of the changes > that aren't tied to JSR issues into jdk9/dev to unblock others. > > Specifically, I'd like to bring over the changes that are needed to allow > jlink to suppo

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

I’ve put out another webrev, http://cr.openjdk.java.net/~sdrach/8156499/webrev.05/ , that addresses Mandy’s concerns. In particular I demonstrate that the resultant image is “runnable” and that a Main class in the image can/cannot find the

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

Thanks for this new proposal, I am (unsurprisingly) happy with it. The use of 'open' and 'opens' seems to work well too. Stephen On 27 Oct 2016 6:08 p.m., wrote: > Thanks to everyone who commented on the weak-modules proposal. I've > just posted a third proposal for #ReflectiveAccessToNonExport

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

> On Oct 27, 2016, at 3:28 PM, Brent Christian > wrote: > > Hi, Mandy > > It looks pretty good to me. Just a couple small things: > > * StackTraceElement.java > > 379 ClassLoader loader = cls.getClassLoader0(); > > It looks as if 'loader' isn't used…? Good catch. Leftover cod

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

> On Oct 27, 2016, at 3:01 AM, Alan Bateman wrote: > > One thing to check is getHashedModuleNames where it assumes the boot Layer > exists, I assume this has the potential to NPE if we have any cases where a > stack trace is printed during early startup. > Good catch. It should only call Has

Re: Request Review: JDK-6479237 (cl) Add support for classloader names

> On Oct 27, 2016, at 8:04 AM, David M. Lloyd wrote: > > OK Thanks. I was looking at the StackTraceElement#toString JavaDoc and it > was not very clear if this was the expected output; maybe it's worth pointing > out explicitly. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6479237/javadoc