RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

Hi folks, as nothing has substantially moved towards approval of the patch [1] and the corresponding CSR [2], let's split the issue into its constituents. The CSR is currently finalized and needs a further review for approval. This requires much less time than a review of the implementation

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

I realized we also need better detection of arch for deb control file. It can be done by using 'dpkg --print-architecture' on host. LinuxDebBundler was corrected. New webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.04/ Patch was re-tested together with webrev.02 from JDK-8228402.

RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll

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). [1] https://bugs.openjdk.java.net/browse/JDK-8227684 [2] http://cr.openjdk.java.net/~herrick/8227684/webrev.01/ Submitted by: Robert Lichtenberger

RFR: JDK-8227312: Remove pkg bundle from DMG image.

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). [1] https://bugs.openjdk.java.net/browse/JDK-8227312 [2] http://cr.openjdk.java.net/~herrick/8227312/webrev.01/ /Andy

RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings

Thanks Martin . May I get a second review ? Best regards, Matthias From: Doerr, Martin Sent: Mittwoch, 24. Juli 2019 12:14 To: Baesken, Matthias ; 'hotspot-...@openjdk.java.net' ; core-libs-dev@openjdk.java.net; net-...@openjdk.java.net Cc: 'ppc-aix-port-...@openjdk.java.net' Subject: RE:

Benchmarking of new optimized Dual-Pivot Quicksort

Hi all, With the help of Laurent Bourges I run benchmarking of new optimized Dual-Pivot Quicksort and summarized results. The tests were run for all types (int / long / ... / double), for both types: sequential and parallel sorting, for small, medium and large sizes. The comparison was done on

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Naoto, TestZoneInfo310.java: With the composition of the tzdir path up and over to the make directory for the tzdir it might be useful to do an explicit check that the directory exists. That way if the directory structure on the build side changes, there will be a test failure makine it

Re: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll

It looks fine. -- Kevin On 7/25/2019 6:20 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). [1] https://bugs.openjdk.java.net/browse/JDK-8227684 [2]

Re: RFR: JDK-8227312: Remove pkg bundle from DMG image.

Looks fine. -- Kevin On 7/25/2019 6:24 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). [1] https://bugs.openjdk.java.net/browse/JDK-8227312 [2]

RFR: 8228623 : Update copyright year to 2019 for several java properties file

Hi, Please review this trivial change to correct the copyright year in several java properties file. I updated the copyright year in English, Simplified Chinese and Japanese resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228623 Webrev:

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Build change looks good. /Erik On 2019-07-24 15:24, naoto.s...@oracle.com wrote: Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While

Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

This patch fixes Lookup.unreflectSpecial to pass the declaring class of Method being unreflected (rather than null) so that it can accurately check if the special caller class is either the lookup class or a superinterface of the declaring class. Webrev:

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Hi Dmitry, Looks good. Thanks, Alexander On 7/25/2019 5:38 AM, Dmitry Chuyko wrote: I realized we also need better detection of arch for deb control file. It can be done by using 'dpkg --print-architecture' on host. LinuxDebBundler was corrected. New webrev:

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Roger, On 7/25/19 7:47 AM, Roger Riggs wrote: Hi Naoto, TestZoneInfo310.java: With the composition of the tzdir path up and over to the make directory for the tzdir it might be useful to do an explicit check that the directory exists. That way if the directory structure on the build side

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

Brian, Thanks a lot for picking up a bug I filled back in 2015. This looks like a good cleanup! I'm a bit concerned though with the added `finally` block in L98. Could that lead to a subtle behavioral change for (an unlikely) case where a `read` method exhausts the current stream, then tries to

Re: RFR: 8228623 : Update copyright year to 2019 for several java properties file

Hi Leo, Looks good to me. I rather prefer noreg-l10n other than noreg-doc for the Jira issue label. Naoto On 7/25/19 9:27 AM, li.ji...@oracle.com wrote: Hi, Please review this trivial change to correct the copyright year in several java properties file. I updated the copyright year in

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

Hi Pavel, > On Jul 25, 2019, at 12:43 PM, Pavel Rappo wrote: > > Thanks a lot for picking up a bug I filled back in 2015. This looks like a > good > cleanup! Thanks for looking at it. > I'm a bit concerned though with the added `finally` block in L98. Could that > lead to a subtle behavioral

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Joe, Yes, I only removed not in-use files, i.e., 2 & 4. I sent the previous email just after confirming that all tests (open/closed) passed on a platform :-) Naoto On 7/25/19 2:24 PM, Joe Wang wrote: Hi Naoto, The legacy trap :-) Relevant files: 1. make/data/tzdata/jdk11_backward 2.

Re: RFR: JDK-8227312: Remove pkg bundle from DMG image.

Looks fine. On 7/25/2019 8:24 AM, Kevin Rushforth wrote: Looks fine. -- Kevin On 7/25/2019 6:24 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). [1]

RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code

Please review a quite fix in a validation source where a String comparison was made as references. JBS: https://bugs.openjdk.java.net/browse/JDK-8068376 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8068376/webrev/ Thanks, Joe

Re: RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code

Hi Joe The change looks reasonable :-) > On Jul 25, 2019, at 6:28 PM, Joe Wang wrote: > > Please review a quite fix in a validation source where a String comparison > was made as references. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8068376 > webrev:

Re: RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code

Thanks Lance! -Joe On 7/25/19 4:04 PM, Lance Andersen wrote: Hi Joe The change looks reasonable :-) On Jul 25, 2019, at 6:28 PM, Joe Wang > wrote: Please review a quite fix in a validation source where a String comparison was made as references. JBS:

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Naoto, The legacy trap :-) Relevant files: 1. make/data/tzdata/jdk11_backward 2. test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward 3. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_backward 4. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward I see you reverted changes to (1)

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

> On Jul 11, 2019, at 12:52 AM, Peter Levart wrote: > > On 7/11/19 9:47 AM, Peter Levart wrote: >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ >> >> >> >> >

Re: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll

Do you know if all 32-bit builds will have "_JLI_Launch@56"? Also, I think @56 is ordinal which can be used to load function by this number instead of the name, so I do not think you need to specify it. My suggestion is to try "JLI_Launch" first and then "_JLI_Launch" and then

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Looks all good Naoto :-) -Joe On 7/25/19 2:35 PM, naoto.s...@oracle.com wrote: Hi Joe, Yes, I only removed not in-use files, i.e., 2 & 4. I sent the previous email just after confirming that all tests (open/closed) passed on a platform :-) Naoto On 7/25/19 2:24 PM, Joe Wang wrote: Hi

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

> On Jul 25, 2019, at 3:42 PM, Brian Burkhalter > wrote: > > the deletion order is (I think) file1, file2, file3 which is the reverse of > the order of initial registration. I intended *not* the reverse order of initial registration. Brian