Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

I disagree with a couple of these changes, but they can be fixed in a subsequent pass, since you've already pushed the changes. By convention, class names are camel case with leading upper-case letter, so ClassName expresses that better than className. Similarly, MyJar.jar seems better to me t

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

Looks good. - Alexey On 11/8/2019 4:31 PM, Andy Herrick wrote: revised [3] as per below suggestions. [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03 /Andy On 11/8/2019 4:07 PM, Alexey Semenyuk wrote: This is minor and not directly related to this change, but looks like we have in

Re: [PATCH] Enhancement proposal for usage of Method::getParameterTypes

Hi, some or all of these were pointed out as part of https://bugs.openjdk.java.net/browse/JDK-8029019 There was a patch out for review early 2017. I'm not sure what happened to that? Either way I think it might make sense to get this small and trivial enhancement separated out and fixed. Thank

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

Looks good. On 11/8/2019 1:31 PM, Andy Herrick wrote: revised [3] as per below suggestions. [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03 /Andy On 11/8/2019 4:07 PM, Alexey Semenyuk wrote: This is minor and not directly related to this change, but looks like we have inconsistenc

Re: RFR: JDK-8233636: Make jpackage an incubator and remove tool provider implementation

Looks good. On 11/8/2019 11:38 AM, Andy Herrick wrote: Please review the revised jpackage fix for bug [1] at [3]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This webrev (webrev.03) addresses feedback from previous version (webrev.02). [1] ht

[PATCH] Enhancement proposal for usage of Method::getParameterTypes

Hello, it seems like Method.getParameterTypes() is often misused in JDK (and beyond): array returned from the method is used only to acquire number of method params by retrieving array.length. The problem here is that Method.getPatameterTypes() clones underlying array and returns the copy. Inst

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

revised [3] as per below suggestions. [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03 /Andy On 11/8/2019 4:07 PM, Alexey Semenyuk wrote: This is minor and not directly related to this change, but looks like we have inconsistency in names in Sample usages. Names used: modulePath, Mod

Re: RFR: JDK-8233591: Reorder jpackage help text to focus on package

This is minor and not directly related to this change, but looks like we have inconsistency in names in Sample usages. Names used: modulePath, ModulePath, moduleName, className, moduleName/ClassName, moduleName/className, package.ClassName, inputdir, MyJar.jar, appRuntimeImage, name, . I'd sugge

Re: RFR: JDK-8233636: Make jpackage an incubator and remove tool provider implementation

Looks good. - Alexey On 11/8/2019 2:38 PM, Andy Herrick wrote: Please review the revised jpackage fix for bug [1] at [3]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This webrev (webrev.03) addresses feedback from previous version (webrev.02).

RFR: JDK-8233591: Reorder jpackage help text to focus on package

Please review the revised jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This fix (webrev.02) was revised after feedback from webrev.01. [1] https://bugs.openjdk.java.net/browse/JDK-8233591 [2] http://cr.openjdk.jav

Re: RFR: JDK-8233636: Make jpackage an incubator and remove tool provider implementation

Please review the revised jpackage fix for bug [1] at [3]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This webrev (webrev.03) addresses feedback from previous version (webrev.02). [1] https://bugs.openjdk.java.net/browse/JDK-8233636 [2] https

Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory

Thanks for looking at the changeset. A small change to eliminate unnecessary object allocations, that's the whole purpose, and what makes it worth the effort. As for the exact numbers (of how much it might save), it depends on users/customers' environment. In terms of keeping in sync, we do

Re: RFR: JDK-823359: Reorder jpackage help text to focus on package

It seems fine, but it might be even better to have both the non-modular and modular application examples be for the default package case and have a single example of --app-image. Also, I presume `--package-type` will be replaced with `--type` (or `-t`) to match the change in command line option

Re: RFR: JDK-823359: Reorder jpackage help text to focus on package

Looks good On 11/8/2019 11:03 AM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This fix reorders the sample usage in the help text. [1] https://bugs.openjdk.java.net/browse/J

Re: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Hi Jim, the tokenizer changes looks good. I was very confused by the dance between: // Indicate that the final string should have escapes translated. shouldTranslateEscapes = true; This: // Conditionally translate or validate escape sequence and add result to string buffe

RFR: JDK-823359: Reorder jpackage help text to focus on package

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This fix reorders the sample usage in the help text. [1] https://bugs.openjdk.java.net/browse/JDK-8233591 [2] https://cr.openjdk.java.net/~herrick/823

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

Hi Alan The method you propose: [nio.]Files[.write](aFile.toPath, lines) adds a trailing blank line to the file; the regression test needs to generate a file without a trailing blank line as this is the condition in which the bug occurs. This is why it now writes out an array of bytes Cheers

RE: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

Hi Mandy, Sorry for the delay in responding. Mandy Chung wrote on 29/10/2019 19:30:55: > From: Mandy Chung > To: Adam Farley8 > Cc: core-libs-dev > Date: 29/10/2019 19:31 > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > for Specific Classes > > Hi Adam, > > It'd be

Re: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Updated webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.01/index.html > On Nov 7, 2019, at 5:23 PM, Brent Christian > wrote: > > Should the new escapes be added to the table in the String.translateEscapes() > Java

Re: RFR: JDK-8233636: Make jpackage an incubator and remove tool provider implementation

On 11/7/2019 5:38 PM, Alexey Semenyuk wrote: http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html:50 I'd suggest to replace --- if (name.equals("jpackage")) --- with more robust --- if (this == JPACKAGE) --- http:

Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory

This does save object allocations and churn, not memory footprint I guess. The namespace mapping contains multiple stacks (with object arrays) and a hashtable and initialized records, so it seems to allocate a few kb on every node visited. (But 100MB allocation does sound like a very constructed

Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

On 07/11/2019 22:55, Henry Jen wrote: Hi, Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this. Looks okay although in the test, the createAFile helper method

Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory

Hi Joe, Fix looks OK to me , but i am not able to understand how come "NamespaceMappings" instance can increase memory uses from (20MB to 140MB ). Current scope of "ns" is "case Node.ELEMENT_NODE:" block and "NamespaceMapping" seems to be very lightweight class. Thanks, Vyom On Fri, Nov 8,