Re: jpackage custom resources not found

> On Jan 15, 2019, at 6:55 PM, Scott Palmer wrote: > > > You are explicitly invoking commands of that JDK. What would you expect if > you ran ‘~/Documents/jdk-13.jdk/Contents/home/bin/java’ ? You are explicitly invoking a binary executable. I would of expected it to try and run against

Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

Good catch on the 3-argument joining in this case; I'll push with that amendment. Thanks for the review, -Joe On 1/15/2019 3:19 PM, Stuart Marks wrote: On 1/14/19 7:41 PM, Joe Darcy wrote: PS And for good measure, made analogous changes in Executable.java:

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. # HG changeset patch # User patrickz # Date 1546508379 -28800 # Thu Jan 03 17:39:39 2019 +0800 # Node ID 0a90eb1de8e4e6c87a6643072e00645d5dde9da2 # Parent

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Re-generated the patch in pure text using “hg export -o” instead of webrev, perhaps this could work (see attached please). Comments had been updated as well according to David’s input. Thanks Regards Patrick From: Roger Riggs Sent: Tuesday, January 15, 2019 11:26 PM To: Patrick Zhang Cc:

Re: jpackage custom resources not found

> On Jan 15, 2019, at 11:43 AM, Michael Hall wrote: >> On Jan 15, 2019, at 10:35 AM, Andy Herrick wrote: >> On 1/15/2019 11:25 AM, Michael Hall wrote: On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: On 1/15/2019 11:04 AM, Michael Hall wrote: > java -version > openjdk

Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

On 1/14/19 7:41 PM, Joe Darcy wrote: PS And for good measure, made analogous changes in Executable.java:     http://cr.openjdk.java.net/~darcy/8217000.1/ Thanks for following up on this. Overall, looks good. One point: 114 sb.append('('); 115 116

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

> On Jan 15, 2019, at 3:55 PM, Alan Bateman wrote: > > > > On 15/01/2019 18:59, Lance Andersen wrote: >> >> OK thank you. I made a ‘minor update to the comments and removed “4" > Looks good. I also skimmed the update test and it looks okay too except setUp > and tearDown where it still

Re: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH

+1 Thanks, David On 16/01/2019 1:03 am, Roger Riggs wrote: Hi Goetz, Looks fine. Removing unnecessary special case code is great! Thanks, Roger On 01/15/2019 07:49 AM, Lindenmaier, Goetz wrote: Hi, As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has

Re: jpackage custom resources not found

> On Jan 15, 2019, at 12:48 PM, Rachel Greenham > wrote: > > On 15/01/2019 17:36, Michael Hall wrote: >>> On Jan 15, 2019, at 10:55 AM, Rachel Greenham >>> wrote: >>> >>> My understanding was that this particular jdk build only exists for the >>> sake of getting jpackage out there into

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

On 15/01/2019 18:59, Lance Andersen wrote: OK thank you.  I made a ‘minor update to the comments and removed “4" Looks good. I also skimmed the update test and it looks okay too except setUp and tearDown where it still catches exception so the methods succeed when they fail. Maybe setUp

Re: RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent

On 15/01/2019 20:48, Roger Riggs wrote: Please review a doc-only change to serial filter descriptions to use the term "system-wide" to describe the scope of configurable filters. Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-system-wide-8202675/ CSR:  

Re: RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent

Looks fine Roger and aligns with the CSR as expected :-) > On Jan 15, 2019, at 3:48 PM, Roger Riggs wrote: > > Please review a doc-only change to serial filter descriptions to use the term > "system-wide" to describe the scope of configurable filters. > > Webrev: >

RFR 8202675 : Replace process-wide terminology in serial filtering to be consistent

Please review a doc-only change to serial filter descriptions to use the term "system-wide" to describe the scope of configurable filters. Webrev:   http://cr.openjdk.java.net/~rriggs/webrev-system-wide-8202675/ CSR:   https://bugs.openjdk.java.net/browse/JDK-8216289 Thanks, Roger

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

Hi Christoph > On Jan 15, 2019, at 3:10 AM, Langer, Christoph > wrote: > > Hi Lance, > >> Thank you for the feedback, please see below > Welcome, thanks for addressing my findings  > >> line 97: spelling: “filter” >> fixed though was “DirectoryStream.Filter” which I changed to >>

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

> On Jan 15, 2019, at 4:07 AM, Alan Bateman wrote: > > On 15/01/2019 00:13, Lance Andersen wrote: >> : >> >> Thank you Alan pointing out this example which the previous fix also did not >> address. I updated the change which addresses the above example as well as >> the relative path >>

Re: jpackage custom resources not found

On 15/01/2019 17:36, Michael Hall wrote: On Jan 15, 2019, at 10:55 AM, Rachel Greenham wrote: My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), True, which

Re: jpackage custom resources not found

> On Jan 15, 2019, at 10:55 AM, Rachel Greenham > wrote: > > My understanding was that this particular jdk build only exists for the sake > of getting jpackage out there into our hands (hence my point about putting it > out as a jlinked app instead), True, which is a little different in

Re: jpackage custom resources not found

My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), and if you want to play with jdk13-ea in its own right, should probably get a fresh one to do just that, as

Re: jpackage custom resources not found

> On Jan 15, 2019, at 10:35 AM, Andy Herrick wrote: > > > On 1/15/2019 11:25 AM, Michael Hall wrote: >>> On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: >>> >>> >>> On 1/15/2019 11:04 AM, Michael Hall wrote: java -version openjdk version "12-internal" 2019-03-19 OpenJDK

Re: jpackage custom resources not found

On 1/15/2019 11:25 AM, Michael Hall wrote: On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: On 1/15/2019 11:04 AM, Michael Hall wrote: java -version openjdk version "12-internal" 2019-03-19 OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) OpenJDK 64-Bit Server VM (build

Re: jpackage custom resources not found

> On Jan 15, 2019, at 10:25 AM, Rachel Greenham > wrote: > > ... simply that you don't *want* jpackage's jdk to be in your path, you don't > want it to be the default, you *only* want it to run jpackage *itself*, in > create-image using --runtime-image pointing to your already jlinked

Re: jpackage custom resources not found

> On Jan 15, 2019, at 10:19 AM, Andy Herrick wrote: > > > On 1/15/2019 11:04 AM, Michael Hall wrote: >> java -version >> openjdk version "12-internal" 2019-03-19 >> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) >> OpenJDK 64-Bit Server VM (build

Re: jpackage custom resources not found

... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to be the default, you *only* want it to run jpackage *itself*, in create-image using --runtime-image pointing to your already jlinked runtime image using your usual JDK; then in create-installer, using

Re: jpackage custom resources not found

On 1/15/2019 11:04 AM, Michael Hall wrote: java -version openjdk version "12-internal" 2019-03-19 OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7) OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing) This is the first jpackage EA build that

Re: jpackage custom resources not found

> On Jan 15, 2019, at 9:18 AM, Rachel Greenham wrote: > > surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: > emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, > and then it doesn't get in the way of anything else. When you want to use >

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

Hi, I'd suggest using 2002, 2019, for the copyright, since much of the code in the new file comes from an older source. $.02, Roger On 01/15/2019 10:43 AM, Alan Bateman wrote: On 15/01/2019 00:51, Ichiroh Takiguchi wrote: Hello Alan. Could you review the fix again ? Bug:   

RE: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH

Hi Roger, thanks for the review! Best regards, Goetz. > -Original Message- > From: core-libs-dev On Behalf Of > Roger Riggs > Sent: Dienstag, 15. Januar 2019 16:04 > To: core-libs-dev@openjdk.java.net > Subject: Re: RFR(S): 8217044: [aix] Launcher still adds old path to jli >

Re: RFR: 8214533 IBM-29626C is required for AIX default charset

On 15/01/2019 00:51, Ichiroh Takiguchi wrote: Hello Alan. Could you review the fix again ? Bug:    https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.01/ I added IBM29626C charset as standard way. Please give any suggestion and

Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Hi Patrick, Attaching just the patch file that is text works fine and it can be applied directly using patch. I don't find a patch in your emails that I can apply directly (or am using the wrong tool). The allowed attachment types are occasionally mentioned.  [1] Thanks, Roger [1]

Re: jpackage custom resources not found

surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you

Re: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH

Hi Goetz, Looks fine. Removing unnecessary special case code is great! Thanks, Roger On 01/15/2019 07:49 AM, Lindenmaier, Goetz wrote: Hi, As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to

Re: jpackage custom resources not found

I am running High Sierra too (10.13.3), and don't see this error with a simple test app. can you share with me the command options used, also if you specify --resource-dir what is in the directory pointed to ? /Andy On 1/15/2019 9:23 AM, Kustaa Nyholm wrote: On 15 Jan 2019, at 16.11, Andy

Re: jpackage custom resources not found

> On 15 Jan 2019, at 16.11, Andy Herrick wrote: > > You can do this all in one step "${PACKAGER} create-installer dmg " Thank you for you help, I appreciate it. I tested above and it fails with what looks suspiciously same error I was experiencing with javapackager and jpackager, see

Re: jpackage custom resources not found

On 1/15/2019 12:08 AM, Kustaa Nyholm wrote: Seems to work not! Thanks! Some small quibbles: The build directory is not kept or used: Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize) Kept working

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

Hi Andy, This is looking really sweet from a build perspective! Just a few minor nits: * In Launcher-jdk.jpackage.gmk, please indent the else clause ("$(eval $(call SetupBuildLauncher, jpackage ") two spaces. * In Lib-jdk.jpackage.gmk, I think there's still room to prune some more

RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH

Hi, As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to LIBPATH anyways, so we can remove the special case for AIX. Please review this small cleanup.

Re: jpackage custom resources not found

> On 15 Jan 2019, at 12.57, Michael Hall wrote: > > Usually the latest jdk with the command would be the one you’d want? Funnily enough, I wanted to quickly test something (jdeps) from the command line, and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal is to

Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

* Joe Darcy: > - sb.append(Stream.of(typeparms).map(Class::typeVarBounds). > -  collect(Collectors.joining(",", "<", ">"))); > +    sb.append(Arrays.stream(typeparms) > +  .map(Class::typeVarBounds) > + 

Re: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Hi Patrick, On 15/01/2019 7:24 pm, Patrick Zhang wrote: In case the attachment may get dropped by mailing system, I paste the udiffs in text here. Yes attachments are generally dropped. ./src/jdk.pack/share/native/common-unpack/zip.cpp rev

Re: jpackage custom resources not found

> On Jan 14, 2019, at 11:50 PM, Kustaa Nyholm > wrote: > > > >> On 15 Jan 2019, at 7.36, Michael Hall wrote: >> >> FWIW, for OS X I just set this in my .bash_profile > > Thanks, my preference is to be explicit so that my build don't depend on the > environment > and changes to it , I've

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

In case the attachment may get dropped by mailing system, I paste the udiffs in text here. ./src/jdk.pack/share/native/common-unpack/zip.cpp rev 53300 : 8215976: Fix gmtime_r declaration

Re: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

On 15/01/2019 00:13, Lance Andersen wrote: : Thank you Alan pointing out this example which the previous fix also did not address.  I updated the change which addresses the above example as well as the relative path Please see http://cr.openjdk.java.net/~lancea/8211919/webrev.02/index.html

RE: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

Hi Roger, Thanks for your review firstly. Attached is the latest patch rebased on today's tip of jdk/jdk (http://hg.openjdk.java.net/jdk/jdk/rev/0b2574a2a6c7). <> Yes there is a "#ifndef _MSC_VER" at line 36, while I think we'd better keep this "#ifdef _MSC_VER" here, as such the declaration

RE: RFR 8211919: ZipDirectoryStream should provide a stream of paths that are relative to the directory

Hi Lance, > Thank you for the feedback, please see below Welcome, thanks for addressing my findings  > line 97: spelling: “filter” > fixed though was “DirectoryStream.Filter” which I changed to > DirectoryStream filter Hm, not quite yet... What I mean is still in line 96: * Iterator