March 2020 - core-libs-dev

[15] RFR: 8240626: Some of the java.time.chrono.Eras return empty display name for some styles and locales
by naoto.sato＠oracle.com 14 Mar '20

14 Mar '20

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8240626 The proposed chageset is located at: https://cr.openjdk.java.net/~naoto/8240626/webrev.00/ In some locales, CLDR only provides partial translations of era names, e.g., only HEISEI and REIWA are provided for Japanese Calendar in Greek locale. CLDRConverter needs to supplement those missing translations from parent locales. Naoto

2 3

RFR [15/java.xml] 8240982 Incorrect copyright header in BCEL 6.4.1 sources
by Joe Wang 13 Mar '20

13 Mar '20

Please review a quick fix for the missing commas after the 2nd year in the copyright header: diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more diff --git a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java --- a/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java +++ b/src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2020 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more Thanks, Joe

3 3

RFR: [small,docs] JDK-8240971 Fix CSS styles in some doc comments
by Jonathan Gibbons 13 Mar '20

13 Mar '20

Please review a simple fix regarding the non-standard use of some CSS in some doc comments. From the JBS Description: Recently, for the display of javadoc block tags, javadoc changed from using an inconsistent set of CSS class names on the generated 'dt' elements to using a single new name ("notes") on the enclosing 'dl' element. There are a few (4) places in the main JDK code where the old-style names were used explicitly in doc comments, in order to emulate the appearance of a list of block tags. These use-sites should be fixed up. They are in the following files: open/src/java.base/share/classes/module-info.java open/src/java.se/share/classes/module-info.java open/src/java.management.rmi/share/classes/module-info.java open/src/jdk.jconsole/share/classes/module-info.java In addition, these four files used the style attribute to force the font to be used. The font is now set in the standard CSS for "notes", and so the local use of a "style" attribute is no longer necessary. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8240971 Webrev: http://cr.openjdk.java.net/~jjg/8240971/webrev.00/index.html API: http://cr.openjdk.java.net/~jjg/8240971/api.00/index.html

4 4

RFR 8240704: CheckHandles.java failed "AssertionError: Handle use increased by more than 10 percent."
by Roger Riggs 12 Mar '20

12 Mar '20

Please review a test improvement to avoid counting unexpected handles. The test for 8239893[1]failed when non-test activities used handles. The test is modified to do a warmup phase spawning some processes and cleaning up. It then runs the test to create processes looking for no significant increase in handles. The execution mode is limited to the interpreter to avoid potential side effects of compilation. The error condition was corrected to look only for increases in the number of handles. Previously, it looked for a 10% delta between the minimum and maximum count of handles. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704/ Issue: https://bugs.openjdk.java.net/browse/JDK-8240704 Thanks, Roger [1] 8239893 <https://bugs.openjdk.java.net/browse/JDK-8239893> Windows handle Leak when starting processes using ProcessBuilder

2 3

[15] RFR: 8216332: Grapheme regex does not work with emoji sequences
by naoto.sato＠oracle.com 12 Mar '20

12 Mar '20

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216332 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8216332/webrev.00/ Before this fix, the rule GB11 (Do not break within emoji modifier sequences or emoji zwj sequences [1]) was only applied once, and was ignored thereafter for the repeated possible rule candidates. The fix is to simply stop resetting the GB11 mode. Naoto [1] https://unicode.org/reports/tr29/#GB11

2 2

RFR 8240957: Clarify BadAttributeValueExpException readObject method
by Roger Riggs 12 Mar '20

12 Mar '20

The change for 8232622: Technical debt in BadAttributeValueExpException failed to document the behavior of the readObject method to ensure compatibility. Please review the javadoc for the readObject method. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-readobject-doc-8240957/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8232622 [2] CSR: https://bugs.openjdk.java.net/browse/JDK-8240314

2 1

RFR(S): 8240734: ModuleHashes attribute not reproducible between builds
by Yangfei (Felix) 12 Mar '20

12 Mar '20

Hi, We found module-info.class in java.base.jmod is not always consistent across different builds. The ModuleHashes attribute in this module-info.class is not reproducible between builds. Patch fixes the issue by using TreeMap instead of HashMap when computing ModuleHashes. Bug: https://bugs.openjdk.java.net/browse/JDK-8240734 Webrev: http://cr.openjdk.java.net/~fyang/8240734/webrev.00/ Passed tier1 test. Please review. Thanks, Felix

5 13

Review Request JDK-8228336: Refactor native library loading implementation
by Mandy Chung 12 Mar '20

12 Mar '20

This patch refactors the native library loading implementation out of ClassLoader and move them to jdk.internal.loader package. This introduces a new NativeLibraries abstraction which loads and registers the loaded native libraries. Previously it was maintained in a nativeLibrary map in each ClassLoader instance and one systemNativeLibraries for the null loader case. With this change, each ClassLoader and BootLoader have its own NativeLibraries instead. NativeLibraries.java and NativeLibraries.c are mostly refactored from the existing code. Only minor cleanups are applied. This refactoring enables Panama LookupLibrary to further experiment and allow loading of a native library without the restriction that a native library can only be loaded by one class loader. The restriction is important for System::loadLibrary in loading JNI libraries that implements JNI native methods and so remain unchanged. This patch follows up the change introduced by JDK-8227587 which adds BootLoader::loadLibrary. It should belong a helper classes instead of BootLoader and this helper method is to avoid doPrivileged call if no security manager is installed for startup performance improvement. Several `privilegedXXX` methods were added for the same purpose for example sun.security.action.GetPropertyAction::privilegedGetProperty and privilegedGetProperties. So I think sun.security.action.LoadLibraryAction is a proper place. Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8228336/webrev.00/ Thanks Mandy

5 8

RFR: removing dead code from jar tool
by Adam Sotona 11 Mar '20

11 Mar '20

Hi, I would like to ask for review of the attached patch removing dead code from jar tool Class files sun.tools.jar.Manifest and sun.tools.jar.SignatureFile appear to be dead code and should be removed. Build with the patch passes all Tier1, Tier2 and Tier3 tests. Thank you, Adam

4 10

RFR: 8240725: Some functions might not work with CJK character
by Yasumasa Suenaga 11 Mar '20

11 Mar '20

Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8240725 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240725/webrev.00/ We found the issue that HotSpot does not start when it is deployed on the path which contains CJK character(s), and it has been fixed in JDK-8240197. On the review of JDK-8240197 [1], we concern similar issue might occur in other place, and I found potentially problem in below: - ZFILE_Open() @ zip_util.c - JDK_Canonicalize() @ canonicalize_md.c (for Windows) - create_unc_path() @ java_md.c (for Windows) - Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp This change passed tests on submit repo (mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139). Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/0383…

3 9