Re: [RFR]: Per thread IO statistics in JFR

On 17/01/2019 5:23 pm, Thomas Stüfe wrote: On Thu, Jan 17, 2019 at 1:23 AM David Holmes > wrote: On 17/01/2019 12:59 am, Alan Bateman wrote: > > Thanks for forwarding as this is a topic that will require a lot of > discussion and agreement fr

Re: [RFR]: Per thread IO statistics in JFR

On Thu, Jan 17, 2019 at 1:23 AM David Holmes wrote: > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential impact on > > long term maintenance and the potential for

[13] RFR: 8210583: Base64.Encoder incorrectly throws NegativeArraySizeException

Hi, Please review the fix for 8210583 Bug: https://bugs.openjdk.java.net/browse/JDK-8210583 Webrev: http://cr.openjdk.java.net/~nishjain/8210583/webrev.03/ CSR: https://bugs.openjdk.java.net/browse/JDK-8215633 Issue: Base64.Encoder.encode and Base64.Decoder.decode methods incorrectly throw uns

Jpackage Windows shortcuts

Are the flags to create shortcuts in the start menu and on the desktop supposed to be working at this point? I tried them and they had no effect. Scott

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

2019/1/16 16:21:17 -0800, joe.da...@oracle.com: > Rather than naming the enum for the test cases as "CASE", more > conventional naming would be "TestCase" or "Case" for the type itself. Good point. The ALL_CAPS treatment was a holdover from the original. Changed to TestCase. - Mark

Re: [RFR]: Per thread IO statistics in JFR

On 17/01/2019 12:59 am, Alan Bateman wrote: Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you summar

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

Rather than naming the enum for the test cases as "CASE", more conventional naming would be "TestCase" or "Case" for the type itself. -Joe On 1/16/2019 9:30 AM, mark.reinh...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev: https://cr.openjdk.java.net/~mr/rev/821

[13] RFR: 8216969: ParseException thrown for certain months with russian locale

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216969 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216969/webrev.00/ For parsing the context sensitive month 'M', the logic was to look for the best match for the short na

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

2019/1/16 11:45:05 -0800, roger.ri...@oracle.com: > Looks fine. Thanks! > Bump the Copyright to 2019. Will do. - Mark

RE: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

It will be wonderful to have persistent MappedByteBuffer feature proposed by Andrew Dinn in JDK 13. To us it looks to be a seamless extension to the existing API, provides a very good building block for persistent memory support in Java in the current Java paradigm and is directly applicable to

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi Adam, On 1/14/19 9:10 AM, Adam Farley8 wrote: As for the CSR process, I'm unfamiliar with it. I've modified the comment for the unreflectSetter method in the webrev. Do let me know if more needs to be done. The CSR process is straight-forward.  CSR FAQ [1] may help you get started. As for

Re: jpackage usage

Is this a console application? I think the launcher won’t show that. So the program actually runs, it just not displays a console window. Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Skillzore Gaming Gesendet: Mittwoch, Januar 16

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

Hi Mark, Looks fine. Bump the Copyright to 2019. Thanks, Roger On 01/16/2019 12:30 PM, mark.reinh...@oracle.com wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ The fix for 8210669 [1] enabled some tests to run that had not bee

Re: jpackage usage

1.) using --input (-i) without also using --files (-f) means every file in the input directory (. in this case) will be added to the bundle.  This may be fine if you are in a working directory with just what you want. ) in this case where --input and --output dirs are both the same, running the

jpackage usage

Hi! I am trying out jpackage from https://jdk.java.net/jpackage/. I have been trying to figure out how to get it to build a working exe file. I have a helloWorld.jar built by gradle which is runnable and runs fine with "java -jar helloWorld.jar". But when I try to use it to build an exe file, th

12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ The fix for 8210669 [1] enabled some tests to run that had not been running, and perhaps had never run. Amongst these tests was tools/launcher/Test7029048.java, which is meant to ensure that

Re: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

On 16/01/2019 14:43, Baesken, Matthias wrote: Hi Alan , do you think it is good to start a UNIX parse_manifest_md.c too with just a one-liner in it ? Or do you prefer only having the windows - file with the Windows coding and keeping the UNIX one-linerfor open_jarfile in parse_

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

Hi, I can sponsor this. Let me know when the jdk-submit is complete. Thanks, Roger On 01/16/2019 10:03 AM, Alan Bateman wrote: On 16/01/2019 02:30, Patrick Zhang wrote: Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message her

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

On 16/01/2019 02:30, Patrick Zhang wrote: Looks .patch didn't work as an attachment, retry with .txt and paste the text below as well. Sorry for one more message here. I think this patch looks okay and I assume you'll test it in the jdk-submit repo to make sure it builds on all platforms. -Al

Re: [RFR]: Per thread IO statistics in JFR

Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you summarize the approaches that you have explored? I

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Alan , do you think it is good to start a UNIX parse_manifest_md.c too with just a one-liner in it ? Or do you prefer only having the windows - file with the Windows coding and keeping the UNIX one-linerfor open_jarfile in parse_manifest.c ? Best regards, Matthias > -

Re: [RFR]: Per thread IO statistics in JFR

Hi Gunter, (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, respectively. Hope this is not too spammy). This looks all very good. I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, so I am not sure if I am allowed to review the JFR parts. That said, her

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

Hello Alan and Roger. I appreciate your suggestions. Could you review the fix again ? Bug:https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.02/ I used "hg cp" command. If I should use git format, please let me know. I changed C

Re: Lazy memory initialization for Unsafe (calloc vs. malloc)

Hi Markus, (moving to panama-dev) I've been pointed at your message by a colleague, I believe it is very relevant to the context of the Panama offheap API, since that API is internally using unsafe to allocate native memory. As far as I'm aware, our Scope class is internally just calling Unsa

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Alan/Brian, I have finally been able to shelve other commitments and return to this JEP (apologies for the hiatus). https://openjdk.java.net/jeps/8207851 The JEP has been reviewed positively by Stuart Marks (core libs) and Vladimir Kozlov (intrinsics). It has also been warmly welcomed by se

Re: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

On 16/01/2019 09:07, Baesken, Matthias wrote: Hi Alan, I thought having UNIX+Windows code in this case together at one place would be okay . However, if you prefer separating it, should I put it here ? src/java.base/windows/native/libjli/java_md.c Or do you have a better suggestion ?

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

Hi Joe, in j.l.Class, in methodToString, can you change sb.append(getName() + "." + name + "("); to sb.append(getName()).append(".").append(name).append('('); because using the concatenation inside a StringBuilder creates another StringBuilder (java.lang doesn't use the StringConcatFactory).

RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Alan, I thought having UNIX+Windows code in this case together at one place would be okay . However, if you prefer separating it, should I put it here ? src/java.base/windows/native/libjli/java_md.c Or do you have a better suggestion ? Best regards, Matthias > From: Alan Bateman

Re: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

On 16/01/2019 08:42, Baesken, Matthias wrote: Hello, please review this small adjustment to parse_manifest.c . It adds support for extended - length paths (on Window) . (see https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation For extend

RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hello, please review this small adjustment to parse_manifest.c . It adds support for extended - length paths (on Window) . (see https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation For extended length paths ) Additionally , some small me