February 2019 - core-libs-dev

RFR: JDK8U JDK-8202088, JDK-8207152, JDK-8211398, JDK-8180469, JDK-8206120, JDK-8218915, JDK-8217710
by Deepak Kejriwal 21 Feb '19

21 Feb '19

Hi All, Please review the backport of the following bug fixes to jdk8u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8202088"JDK-8202088: Japanese new era implementation. HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8207152"JDK-8207152: Placeholder for Japanese new era should be two characters. HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180469"JDK-8180469 : Wrong short form text for supplemental Japanese era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8217710"JDK-8217710 : Add 5 currency code points to Java SE 8uX Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webr… These code changes are made possible thanks to specification changes already pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c35f231af17a http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/00475cd329f7 Regards, Deepak

4 7

RE: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
by Deepak Kejriwal 21 Feb '19

21 Feb '19

Correcting typo for release. From: Deepak Kejriwal <deepak.kejriwal(a)oracle.com> Sent: Tuesday, February 19, 2019 7:42 PM To: 'core-libs-dev' <core-libs-dev(a)openjdk.java.net>; 'jdk-updates-dev(a)openjdk.java.net' <jdk-updates-dev(a)openjdk.java.net> Subject: RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915 Hi All, Please review the backport of the following bug fixes to jdk11u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ These code changes are made possible thanks to specification change already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace Regards, Deepak

6 11

RFE: add missing methods to Optional, OptionalInt, OptionalLong and OptionalDouble
by Rob Spoor 20 Feb '19

20 Feb '19

I noticed that, while Stream and its primitive equivalents have multiple map and flapMap methods, Optional and its primitive equivalents were missing those. Since these can still be very useful, I wrote a patch to add the following methods: * Optional: mapToInt, mapToLong, mapToDouble, flatMapToInt, flatMapToLong, flatMapToDouble * OptionalInt: map, mapToObj, mapToLong, mapToDouble, flatMap * OptionalLong: map, mapToObj, mapToInt, mapToDouble, flatMap * OptionalDouble: map, mapToObj, mapToInt, mapToLong, flatMap I did not add any more flatMap methods to OptionalInt, OptionalLong and OptionalDouble because these also don't exist on IntStream, LongStream and DoubleStream. In addition, I also added the missing or method to OptionalInt, OptionalLong and OptionalDouble based on that of Optional. My OCA has been processed on 2019-01-22. Rob

2 2

RFR: 8216363: NullPointerException in java.util.logging.Handler#isLoggable
by Daniel Fuchs 20 Feb '19

20 Feb '19

Hi, Please find below a doc fix for: 8216363: NullPointerException in java.util.logging.Handler#isLoggable https://bugs.openjdk.java.net/browse/JDK-8216363 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/index.html java.util.logging.Handler specifies that Handler.isLoggable(null) returns false. Unfortunately, the implementation throws NPE instead. For the sake of backward compatibility - it might be more prudent to simply alter the API specification to document the behavior of the default implementation, while allowing subclasses to change that behavior. In fact, one already does: StreamHandler::isLoggable(LogRecord) already returns false and doesn't throw NPE. best regards, -- daniel

3 12

RFR: JDK-8212091 : Move native code under platform specific folders and files
by Alexander Matveev 20 Feb '19

20 Feb '19

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). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ Thanks, Alexander

4 7

RFR: JDK-8217798: modular jar linking in jpackage
by Andy Herrick 19 Feb '19

19 Feb '19

JDK-8217798: modular jar linking in jpackage 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-8217798 [2] http://cr.openjdk.java.net/~herrick/8217798/ /Andy Herrick

3 2

RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine.
by Zeller, Arno 19 Feb '19

19 Feb '19

Hello! I found that the test java/util/Base64/TestEncodingDecodingLength.java fails on a machine with 8GB memory after JDK-8218265. The test starts a VM with -Xmx8GB but the VM needs some more memory than only the heap and on machines with just 8GB of memory (and no swap configured) the test will always fail because the VM cannot get enough native memory. Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to be safe. Could someone please review this minimal change? Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ Thanks and best regards, Arno

5 5

RFR: JDK11U JDK-8206120, JDK-8211398, JDK-8218915
by Deepak Kejriwal 19 Feb '19

19 Feb '19

Hi All, Please review the backport of the following bug fixes to jdk8u-dev: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8206120"JDK-8206120 : Add test cases for lenient Japanese era parsing HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211398"JDK-8211398 : Square character support for the Japanese new era HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8218915"JDK-8218915 : Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points Webrev: http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.00/ These code changes are made possible thanks to specification change already pushed: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c1e1669edace Regards, Deepak

1 0

RFR(XS):JDK-8219228: java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test machine.
by Baesken, Matthias 19 Feb '19

19 Feb '19

Looks good to me (not a Reviewer however). Best regards, Matthias > > Message: 2 > Date: Mon, 18 Feb 2019 15:35:20 +0000 > From: "Langer, Christoph" <christoph.langer(a)sap.com> > To: "Zeller, Arno" <arno.zeller(a)sap.com>, Nishit Jain > <nishit.jain(a)oracle.com>, Naoto Sato <naoto.sato(a)oracle.com>, > Roger > Riggs <Roger.Riggs(a)oracle.com> > Cc: core-libs-dev <core-libs-dev(a)openjdk.java.net> > Subject: RE: RFR(XS):JDK-8219228: > java/util/Base64/TestEncodingDecodingLength.java failing on 8GB > test > machine. > Message-ID: <a01efd886d8844b5939b09a34163dec7(a)sap.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Arno, > > this looks good and trivial. I'll sponsor this one. > > Maybe one of the authors/reviewers of the original fix for bug > https://bugs.openjdk.java.net/browse/JDK-8218265 (Nishit, Roger, Naoto) > should approve this. > > Thanks > Christoph > > > > -----Original Message----- > > From: core-libs-dev <core-libs-dev-bounces(a)openjdk.java.net> On Behalf > > Of Zeller, Arno > > Sent: Montag, 18. Februar 2019 13:49 > > To: core-libs-dev <core-libs-dev(a)openjdk.java.net> > > Subject: [CAUTION] RFR(XS):JDK-8219228: > > java/util/Base64/TestEncodingDecodingLength.java failing on 8GB test > > machine. > > > > Hello! > > > > I found that the test java/util/Base64/TestEncodingDecodingLength.java > fails > > on a machine with 8GB memory after JDK-8218265. > > The test starts a VM with -Xmx8GB but the VM needs some more memory > > than only the heap and on machines with just 8GB of memory (and no > swap > > configured) the test will always fail because the VM cannot get enough > > native memory. > > Therefore I suggest to increase "@requires os.maxMemory" to >= 10GB to > > be safe. > > > > Could someone please review this minimal change? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219228 > > > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8219228/ > > > > Thanks and best regards, > > Arno

1 0

PATCH. JDK-4887513 Typo in RMIFailureHandler interface doc page
by Andrey Turbanov 19 Feb '19

19 Feb '19

Hello. I would like to contribute a small patch for bug: https://bugs.openjdk.java.net/browse/JDK-4887513 Index: src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java (revision 8df4dc07bd6f5545048485493c2edfc5bab53bbb) +++ src/java.rmi/share/classes/java/rmi/server/RMIFailureHandler.java (date 1550354580517) @@ -43,9 +43,8 @@ * The <code>failure</code> callback is invoked when the RMI * runtime is unable to create a <code>ServerSocket</code> via the * <code>RMISocketFactory</code>. An <code>RMIFailureHandler</code> - * is registered via a call to - * <code>RMISocketFacotry.setFailureHandler</code>. If no failure - * handler is installed, the default behavior is to attempt to + * is registered via a call to <code>RMISocketFactory.setFailureHandler</code>. + * If no failure handler is installed, the default behavior is to attempt to * re-create the ServerSocket. * * @param ex the exception that occurred during <code>ServerSocket</code> Andrey Turbanov

3 5