February 2019 - core-libs-dev

RFR(JDK 13/java.xml) 8180901: Transformer.reset() resets the state only once
by Joe Wang 05 Feb '19

05 Feb '19

Please review a quick fix for preserving the initial state of the Transformer. The faulty impl passes a reference of the initial property setting to the working copy during reset, thus causes it to be altered by an user setting. Further reset would then no longer be able to return to the initial state. JBS: https://bugs.openjdk.java.net/browse/JDK-8180901 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8180901/webrev/ Thanks, Joe

3 3

8218460: Test generation scripts do not invoke stream preprocessor correctly
by Brian Burkhalter 05 Feb '19

05 Feb '19

https://bugs.openjdk.java.net/browse/JDK-8218460 http://cr.openjdk.java.net/~bpb/8218460/webrev.00/ A full test run will be effected with the generated tests except those generated by test/jdk/java/lang/invoke/VarHandles/generate-vh-tests.sh Unfortunately it appears that tests in this folder were modified by manual editing as opposed to modifying the templates and generating the tests via the script. This will be the subject of a linked issue. Thanks, Brian

1 0

RFR(JDK 13/java.xml) 8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false)
by Joe Wang 05 Feb '19

05 Feb '19

Please review a change to the DOM parser so that it complies with the specification with regard to the ExpandEntityReferences feature. This change corrects the behavior so that the resulting DOM tree includes EntityReference nodes but not the expanded Text nodes when the feature is off. It also means that the DOM parser will not attempt to read entity references if any. JBS: https://bugs.openjdk.java.net/browse/JDK-8206132 webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8206132/webrev/ Thanks, Joe

3 6

RFR: JDK-8218186 Clean up CLDR generation in build
by Magnus Ihse Bursie 05 Feb '19

05 Feb '19

The CLDR data is, since Jigsaw, used in two different modules -- java.base and jdk.localedata. Unfortunately, the split between these two modules were not fully finished as part of the Jigsaw project. This patch aims to resolving most of this. The CLDRConverter build tool is now called from Gensrc-java.base and Gensrc-jdk.localedata, for their respective module. The calls have been updated to match modern build-infra standards. Also, the raw CLDR data was located mixed in with the Java source, in jdk.localedata. This patch also moves the data to make/data/cldr, to align with input data to all other build tools. Bug: https://bugs.openjdk.java.net/browse/JDK-8218186 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218186-cleanup-CLDR/webrev.01 /Magnus

4 4

RFR 8218227 : StringBuilder constructor throws confusing NegativeArraySizeException
by Ivan Gerasimov 05 Feb '19

05 Feb '19

Hello! The spec of the constructors StringBuilder(String)/StringBuilder(CharSequence) states that the initial capacity of the builder will be set to the length of the argument plus 16. This causes them to throw confusing NegativeArraySizeException when the argument's length is close to Integer.MAX_VALUE. Let the arguments length be (Integer.MAX_VALUE - DELTA), like in the code below: String str = "Z".repeat(Integer.MAX_VALUE - DELTA); StringBuilder sb = new StringBuilder(str); Currently the behavior is as following: 0 <= DELTA <= 2 - unable to construct str, 2 <= DELTA <= 15 - NegativeArraySizeException is thrown, 16 <= DELTA <= 17 - OutOfMemoryError is thrown, DELTA >= 18 - works fine. With the fix, OOM will be thrown for all DELTA <= 17. Also the fix will make constructing a StringBuilder from UTF16 coded String slightly more efficient. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8218227 WEBREV: http://cr.openjdk.java.net/~igerasim/8218227/00/webrev/ Would you please help review the fix? -- With kind regards, Ivan Gerasimov

2 5

[13] RFR 8217969, 8218265: Base64.Decoder.decode methods ... and java/util/Base64/TestEncodingDecodingLength.java failing
by Nishit Jain 05 Feb '19

05 Feb '19

Hi, Please review the below fix for 8217969 and 8218265 Bug: https://bugs.openjdk.java.net/browse/JDK-8217969 https://bugs.openjdk.java.net/browse/JDK-8218265 Webrev: http://cr.openjdk.java.net/~nishjain/8217969_8218265/webrev.00/ Issue: Fix for 8210583 changed the Base64.Decoder.decode to throw OOME when an integer value overflows, which is an intermediate value, not the final value, the final value is always less than Integer.MAX_VALUE. Also, the test case written for 8210583, fails on certain platforms and throws "OutOfMemoryError: Requested array size exceeds VM limit ", due to the array size of length Integer.MAX_VALUE - 2. Fix: Handled the integer overflow by storing the intermediate value as "long" and converting the final value as integer. Also, updating the test case input array length to Integer.MAX_VALUE - 8, since MAX_VALUE - 2 was used only to test the overflow condition in Decoder.decode() which is no longer there. Regards, Nishit Jain

3 4

RFR: JDK-8217317 : Create jpackage native library for windows
by Alexander Matveev 05 Feb '19

05 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). - jpackage launcher will now build same as Linux and OS X using SetupBuildLauncher. - jpackage.dll was added based on Windows jpackage.exe launcher which will have icon swap and version swap functionality called via JNI. - Some code formatting, clean up and minor improvements where done to icon and version swap code. No functional changes. - Windows registry will be read and enumerated via JNI as well. - isDirectoryInExclusionPath() will use native path comparison, since paths in registry and temp folder returned by Java code can be in short or long format, thus simple string comparison will not work. - Windows Defender workaround warning will be checked for --build-root as well if it is set. - Removed extra escaping from JPackageHelper for Windows, otherwise tests fails due to incorrect escaping. Our launcher used CreateProcess to launch java.exe by passing args from main() to CreateProcess. This is why I think we required extra escaping. [1] https://bugs.openjdk.java.net/browse/JDK-8217317 [2] http://cr.openjdk.java.net/~almatvee/8217317/webrev.00/ Thanks, Alexander

3 5

Collectors.joining() simplified [patch]
by Tomasz Linkowski 05 Feb '19

05 Feb '19

Hi, I found out that `Collectors.joining()` can be simplified as follows: 1) `<CharSequence, StringBuilder, String>` reduced to `<>` 2) `(r1, r2) -> { r1.append(r2); return r1; }` replaced with `StringBuilder::append` If such a small contribution is considered worthwhile, please sponsor it (patch below). Regards, Tomasz Linkowski PS. I've signed the OCA. =================================================================== --- src/java.base/share/classes/java/util/stream/Collectors.java +++ src/java.base/share/classes/java/util/stream/Collectors.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2019, 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 @@ -365,9 +365,8 @@ * {@code String}, in encounter order */ public static Collector<CharSequence, ?, String> joining() { - return new CollectorImpl<CharSequence, StringBuilder, String>( - StringBuilder::new, StringBuilder::append, - (r1, r2) -> { r1.append(r2); return r1; }, + return new CollectorImpl<>( + StringBuilder::new, StringBuilder::append, StringBuilder::append, StringBuilder::toString, CH_NOID); }

1 0

[13]: RFR: 8218386: Correct the SE version in j.l.Character
by Naoto Sato 04 Feb '19

04 Feb '19

Hello, Please review this one line fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218386 The proposed change is here: --- diff -r 213a2377b792 src/java.base/share/classes/java/lang/Character.java --- a/src/java.base/share/classes/java/lang/Character.java +++ b/src/java.base/share/classes/java/lang/Character.java @@ -54,7 +54,7 @@ * from the Unicode Consortium at * <a href="http://www.unicode.org">http://www.unicode.org</a>. * <p> - * The Java SE 12 Platform uses character information from version 11.0 + * The Java SE 13 Platform uses character information from version 11.0 * of the Unicode Standard, plus the Japanese Era code point, * {@code U+32FF}, from the first version of the Unicode Standard * after 11.0 that assigns the code point. --- The "Java SE 12" version string was forward ported automatically from this changeset that made into jdk12 repository: http://hg.openjdk.java.net/jdk/jdk12/rev/4f2af72cb65a which needs to be corrected. Naoto

2 1

RFR - 8212975 - ClassDesc should have a full name method
by Jim Laskey 04 Feb '19

04 Feb '19

Please review the webrev below. Though generally useful for debugging ClassDesc (or using Class::forName), ClassDesc::fullDisplayName allows compiler devs to use a ClassDesc directly to optimally add classes to the symbol table. Past: ClassDesc cd = ... String className = cd.packageName().isEmpty() ? cd.displayName() : cd.packageName() + "." + cd.displayName(); Symbol classSym = names.fromString(className); Future: ClassDesc cd = ... String className = cd.fullDisplayName(); Symbol classSym = names.fromString(className); JBS: https://bugs.openjdk.java.net/browse/JDK-8212975 webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev/index.html

1 0