September 2018 - core-libs-dev

RFR - JDK-8200434 - String::align, String::indent (code review)
by Jim Laskey 06 Sep '18

06 Sep '18

Please review the code for String::align and String::indent at the link below. Notes: Includes a private version of String::isMultiline() which may be made into a public method at some future date Includes minor correctness clean up of StringLatin1.java, StringUTF16.java webrev: http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8200434 Cheers, — Jim

3 4

RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
by Andrew Leonard 06 Sep '18

06 Sep '18

Hi, We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's default compiler options has highlighted a couple of native code issues, with undefined behaviours: - validating loop test array bounds - left shifts of negative values I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 and attached the webrev fix here: http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ This has already been discussed and refined on the "s390x-port-dev" maillist and as it was pointed out, it should have been posted here... I'd like to request a sponsor for this fix please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

5 17

[12] RFR 8042902: Test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails intermittently
by Chris Yin 06 Sep '18

06 Sep '18

Please have a review for below minor change to test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java, thanks The bug has a long history, so a quick summary and explanation here, the issue which caused test failure before 2016 should already been fixed, so this fix change is for new observed failures in 2018. I checked all failures happened on Mac OS platform. The failure is weird that we got different value by call InetAddress.getHostName() on same address one after one in very short time, cannot make sure whether any network configuration change or Mac OS system caused the difference for multiple name reverse lookup, but from this test aspect, guess the focus on address serialization should be enough, so below fix change is simple, we will call InetAddress.getHostName() first to set holder() ’s hostname field in testAllNetworkInterfaces() before serialization test (as Chris Hegarty commented in 2014. And per Mark's comments, "display call was commented out as it was too verbose" so we just simple print hostname instead of get whole display call function back), then when we deserialized the address object and do comparison with original one later, getHostName() call will retrieve holder() ’s hostname value directly, that should eliminate the possible difference when doing name reverse lookup twice. bug: https://bugs.openjdk.java.net/browse/JDK-8042902 changes: diff -r b51d348698c2 test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java --- a/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java Wed Sep 05 19:40:52 2018 -0700 +++ b/test/jdk/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java Thu Sep 06 14:29:38 2018 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -192,6 +192,7 @@ System.err.println("Testing with " + iadr); System.err.println(" scoped iface: " + i6adr.getScopedInterface()); + System.err.println(" hostname: " + i6adr.getHostName()); testInet6AddressSerialization(i6adr, null); } } Regards, Chris

2 2

[PATCH] Simplification of TreeMap
by Сергей Цыпанов 06 Sep '18

06 Sep '18

Hi, currently (latest code of JDK 11) an instance of TreeMap created with no-arg contructor has nullable comparator i.e. utilizes no comparator. As it comes from the code, a TreeMap created with nullable comparator works exactly as a TreeMap created with comparator provided by Comparator.naturalOrder(). This is also explicitly specifid in Javadoc. I propose to initialize default comparator of TreeMap with instance of Comparator returned by Comparator.naturalOrder() instead of null. This allows to remove the code responsible for handling nullable comparator, e. g. TreeMap::getEntryUsingComparator can be completely removed in favour of TreeMap::getEntry. Similar simplification available for TreeMap::put, TreeMap::compare, EntrySpliterator::getComparator. I've prepared a patch for this. The patch contains both described major change and some tiny clean-ups e. g. utilization of Objects::requireNonNull where appropriate and Objects::equals instead of hand-written TreeMap::valEquals. TreeMapTest is green after my changes. Regards, Sergey Tsypanov

5 6

RFR: JDK-8200609 Proper fix for mapfile removal for libjsig
by Magnus Ihse Bursie 05 Sep '18

05 Sep '18

When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out. Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/web… /Magnus

3 4

RFR 8210318: idea.sh script doesn't work on Mac
by Maurizio Cimadamore 05 Sep '18

05 Sep '18

Hi, following the latest updates to the idea.sh script, Mac users reported issues - mostly having to do with usage of 'sed' - more specifically: * sed -i option is not portable - it has different formats in Mac vs. Linux. This patch does without -i, by moving the replaced file onto a temporary file, then moving such file on top of the template file in a subsequent step. This should be more robust. * sed doesn't like newlines in replaced text in Mac. I've thus omitted the newline from the SOURCE template - as that was mostly cosmetic. Thanks for Michael McMahon to report (and figure out how to deal with) these issues, and to Alan Bateman for testing the patch. I also fixed another minor glitch, this time in the langtools-only template - which was still referring to the old ant file location in the various run configuration. Webrev: http://cr.openjdk.java.net/~mcimadamore/8210318/ Cheers Maurizio

4 8

RFR JDK-8210394: (zipfs) jdk/nio/zipfs/ZFSTests.java rootdir.zip: The process cannot access the file because it is being used by another process
by Xueming Shen 05 Sep '18

05 Sep '18

Hi Please help review the change for JDK-8210394. issue: https://bugs.openjdk.java.net/browse/JDK-8210394 webrev: http://cr.openjdk.java.net/~sherman/8210394/webrev It appears the "zipfile" for testing is opened with "new ZipFile(...).stream()..." without explicit close might be the direct trigger of the failure. (a mach5 job with the proposed fix seems to pass without this failure) Thanks, Sherman

3 2

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
by Baesken, Matthias 05 Sep '18

05 Sep '18

Hi Max, thanks for adding yourself as a reviewer. I set the CSR ( https://bugs.openjdk.java.net/browse/JDK-8207768 ) to proposed. Best regards, Matthias > > Message: 2 > Date: Tue, 4 Sep 2018 21:31:58 +0800 > From: Weijun Wang <weijun.wang(a)oracle.com> > To: "Baesken, Matthias" <matthias.baesken(a)sap.com> > Cc: "security-dev(a)openjdk.java.net" <security-dev(a)openjdk.java.net>, > "core-libs-dev(a)openjdk.java.net" <core-libs- > dev(a)openjdk.java.net> > Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest parsing of jar archives > Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3(a)oracle.com> > Content-Type: text/plain; charset=us-ascii > > I've added myself as a reviewer. You might want to set scope to "JDK". > > A CSR is approved by the CSR group after you finalize it. First you should > propose it. If you think it's urgent or trivial, you can also fast-track it. > > Read https://wiki.openjdk.java.net/display/csr/Main for more details. > > Thanks > Max > > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias > <matthias.baesken(a)sap.com> wrote: > > > >> The change looks fine. We can enhance the name if we want to support > .SF > >> parsing later. > >> > >> Please revise your CSR and get it approved first. > > > > Hi Max, Thanks ! > > > > I adjusted the CSR , please approve : > > > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > > > Best regards, Matthias

2 1

RFR(M) : 8210039 : move OSInfo to top level testlibrary
by Igor Ignatyev 04 Sep '18

04 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html > 698 lines changed: 114 ins; 240 del; 344 mod Hi all, could you please review this clean up of jdk testlibrary? the patch updates the tests to use jdk.test.lib.Platform instead of jdk.testlibrary.OSInfo.OSType, cleans up OSInfo and renames it to jdk.test.lib.OSVersion. testing: changed tests + :jdk_desktop test group webrev: http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210039 Thanks, -- Igor

5 8

RFR 8210285 : CharsetDecoder/Encoder's constructor does not reject NaN
by Ivan Gerasimov 04 Sep '18

04 Sep '18

Hello! The javadoc for CharsetDecoder [1] states that an exception is thrown when a non-positive number is passed in as an argument. However we only reject negative or zero numbers, but not NaN. And likewise for CharsetEncoder. Would you please help review a trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210285 WEBREV: http://cr.openjdk.java.net/~igerasim/8210285/00/webrev/ Thanks in advance! [1] https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… -- With kind regards, Ivan Gerasimov

6 8