Re: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages

Phil, Let me provide more details on what is going on here. JDK-8230933 - is the fix of jpackage code assigning icons to main/additional launchers. JDK-8233270 - is primarily the enhancement of jpackage test helpers to provide functionality needed for automated testing of the fix of JDK-82309

Re: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134

http://cr.openjdk.java.net/~almatvee/8235738/webrev.01/ Fixed testForPresenceOnly spelling error. Thanks, Alexander On 12/13/2019 9:39 AM, Phil Race wrote: testForPresenseOnly  It should be spelt testForPresenceOnly -phil. On 12/13/19 6:16 AM, Andy Herrick wrote: I approve these changes.

RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node

Hello! The java.util.regex package contains a debugging utility PrintPattern which is used to display the internal representation structure of a compiled regex pattern. When it prints a node that is linked to another node that has already been printed, it is supposed to print a link, but fai

Re: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134

Looks ugly, but seems to be the only possible fix at the moment. Approved. - Alexey On 12/13/2019 1:01 AM, Alexander Matveev wrote: Please review fix [2] for jpackage bug [1]. Not sure why it happens, but reading output from "hdiutil attach" was not exiting immediately after process terminate

Re: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134

testForPresenseOnly It should be spelt testForPresenceOnly -phil. On 12/13/19 6:16 AM, Andy Herrick wrote: I approve these changes. My first thought was that, if reading output only after Process is complete is valid and safe, then why not do it that way all the time ?  But comment in Pro

Re: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16

I've been trying to contact AdoptOpenJDK folk about this and other related issues. I've not heard back yet. In the meantime, I note that these days it is reasonably easy for folk to build jtreg if they do not have easy access to the latest prebuilt binaries. There's a README in the root of the

Re: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16

Hi Kumar, I haven't heard adoptopenjdk people bringing it up. I agree w/ your hypothesis, this job started to fail after https://hg.openjdk.java.net/code-tools/jtreg/rev/deee95d5d8ff which checks that '.hg' directory exists in the

Re: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString

Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fie

Re: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider

+1 On 12/12/19 7:38 PM, Joe Wang wrote: +1 -Joe On 12/12/19 2:07 PM, naoto.s...@oracle.com wrote: Sorry, I seem to have posted an old webrev, which included unnecessary retrieval of the generic name (4168-4173 in v.00). Here is the correct webrev: http://cr.openjdk.java.net/~naoto/8235238/

Re: jpackage: file-associations report wrong argument count

yes - I can see this problem locally on windows and have filed JDK-8235915 to address it. /Andy On 12/13/2019 2:45 AM, Daniel Peintner wrote: All, I tried to use jpackage file-associations option to associate a given extension. This works fi

Re: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134

Hi Andy, On 13/12/2019 15:16, Andy Herrick wrote: My second thought is that this indicates an underlying unidentified bug in the mac native code used by Process or ProcessBuilder , and although it would be better to identify and resolve the underlying problem, the fix is needed now, so this ch

Re: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16

Hey Igor — please read inlined comment below….. [cc’ed Jon] On Dec 12, 2019, at 10:46 PM, Igor Ignatyev mailto:igor.ignat...@oracle.com>> wrote: On Dec 12, 2019, at 10:21 PM, David Holmes mailto:david.hol...@oracle.com>> wrote: Hi Igor, On 13/12/2019 3:19 pm, Igor Ignatyev wrote: https://na

Re: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134

I approve these changes. My first thought was that, if reading output only after Process is complete is valid and safe, then why not do it that way all the time ?  But comment in Process javadoc: "Because some native platforms only provide limited buffer size for standard input and output stre

RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

Hi Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ A recent GCC patch (supposed to be in GCC 10) exposes a