March 2020 - core-libs-dev

[8u] RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs.
by Severin Gehwolf 06 Mar '20

06 Mar '20

Hi, Please review this 8u backport. The OpenJDK 11u patch does not apply cleanly after path-reshuffeling due to a) test and code for jaxp are split in JDK 8 b) Some rejects in comments - copyright and last modified date. I've omitted rejected comments. I can manually add them if that's preferred. See below. Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 webrevs: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webre… Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on Windows without the fix fails and passes with it. Thanks to Simon Tooke who helped testing this patch on Windows. Rejects: $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej --- XMLEntityManager.java +++ XMLEntityManager.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more @@ -89,7 +89,7 @@ * @author K.Venugopal SUN Microsystems * @author Neeraj Bajaj SUN Microsystems * @author Sunitha Reddy SUN Microsystems - * @LastModified: Oct 2017 + * @LastModified: Nov 2018 */ public class XMLEntityManager implements XMLComponent, XMLEntityResolver { Thoughts? Thanks, Severin

3 6

RFR 8240524: Removed warnings from test classes
by Vipin Sharma 06 Mar '20

06 Mar '20

Hi All, Please review patch to remove warnings from test classes. Bug : https://bugs.openjdk.java.net/browse/JDK-8240524 <https://bugs.openjdk.java.net/browse/JDK-8240524> Webrev : http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/ <http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/> Change description: Class: test/jdk/java/lang/Boolean/GetBoolean.java Fixed following warning: 1. "Exception 'java.lang.Exception' is never thrown in the method” Class: test/jdk/java/lang/Boolean/MakeBooleanComparable.java Fixed following warnings: 1. Explicit type argument Boolean can be replaced with <> 2. C-style array declaration of parameter 'args' Class: test/jdk/java/lang/Boolean/ParseBoolean.java Fixed following warning: 1. Exception 'java.lang.Exception' is never thrown in the method Regards, Vipin

3 2

JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy
by Joe Darcy 05 Mar '20

05 Mar '20

Hello, Where such a mapping exists, it would be helpful to tie the policies represented by various RoundingMode constants to the equivalent rounding attribute defined by IEEE 754-2019, the latest version of the floating-point standard: JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy http://cr.openjdk.java.net/~darcy/8240624.0/ Please review the patch below; I'll update the file copyright year before pushing. Thanks, -Joe --- old/src/java.base/share/classes/java/math/RoundingMode.java 2020-03-05 13:44:23.971037000 -0800 +++ new/src/java.base/share/classes/java/math/RoundingMode.java 2020-03-05 13:44:23.647037000 -0800 @@ -87,6 +87,12 @@ * ({@link BigDecimal#ROUND_UP}, {@link BigDecimal#ROUND_DOWN}, * etc. ). * + * @apiNote + * Five of the rounding modes defined in this class correspond to + * rounding direction attributes defined in IEEE 754-2019. Where + * present, this correspondence will be noted in the documentation of + * the particular constant. + * * @see BigDecimal * @see MathContext * @author Josh Bloch @@ -130,7 +136,9 @@ * Rounding mode to round towards zero. Never increments the digit * prior to a discarded fraction (i.e., truncates). Note that this * rounding mode never increases the magnitude of the calculated value. - * + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardZero. + * *<p>Example: *<table class="striped"> * <caption>Rounding mode DOWN Examples</caption> @@ -159,6 +167,8 @@ * result is positive, behaves as for {@code RoundingMode.UP}; * if negative, behaves as for {@code RoundingMode.DOWN}. Note * that this rounding mode never decreases the calculated value. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardPositive. * *<p>Example: *<table class="striped"> @@ -188,6 +198,8 @@ * result is positive, behave as for {@code RoundingMode.DOWN}; * if negative, behave as for {@code RoundingMode.UP}. Note that * this rounding mode never increases the calculated value. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTowardNegative. * *<p>Example: *<table class="striped"> @@ -219,6 +231,8 @@ * fraction is ≥ 0.5; otherwise, behaves as for * {@code RoundingMode.DOWN}. Note that this is the rounding * mode commonly taught at school. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTiesToAway. * *<p>Example: *<table class="striped"> @@ -286,6 +300,8 @@ * chiefly used in the USA. This rounding mode is analogous to * the rounding policy used for {@code float} and {@code double} * arithmetic in Java. + * This mode corresponds to the IEEE 754-2019 rounding + * attribute roundTiesToEven. * *<p>Example: *<table class="striped">

2 3

jpackage Linux rpath
by Auclair, Andrew 05 Mar '20

05 Mar '20

Hi, We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf. Thanks, Andrew Auclair Software Engineer Tactical Communications Group A Curtiss-Wright Company 2 Highwood Drive, Building 2, Suite 200 Tewksbury, MA 01876-1157 ---------------------------------------------------------------------- This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.

2 4

RFR: 8222000: JFR: Process start event
by Erik Gahlin 05 Mar '20

05 Mar '20

Hi Could I have review of a JFR event that is emitted when a process is started from Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8222000 Webrev: http://cr.openjdk.java.net/~egahlin/8222000/ Testing: tier1,tier2 + jdk/jdk/jfr Thanks Erik

3 4

RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start
by Jaikiran Pai 05 Mar '20

05 Mar '20

Can I please get a review and a sponsor for a patch for https://bugs.openjdk.java.net/browse/JDK-8211917? The webrev containing the patch is available at https://cr.openjdk.java.net/~jpai/webrev/8211917/1/webrev/ The commit in the patch updates the jdk.nio.zipfs.ZipFileSystem to write out the manifest (if any) as the first entry in the LOC. That then allows the java.util.jar.JarInputStream to find the manifest and return it through JarInputStream.getManifest(). In an initial attempt at this patch, I had tried to just reorder the CEN to add the manifest entry first instead of forcing the manifest entry first in the LOC. But that didn't work and the JarInputStream still couldn't find the manifest. So I used this approach to force the manifest as the first entry in the LOC (and the existing code effectively also ensures that it's also the first entry in the CEN). The patch also includes a test case to reproduce this issue and verify the change. In the test case I intentionally used the verbose version of the FileSystem.newFileSystem() API, instead of the newer simpler ones. This is to allow cleaner/easier backporting of this patch to Java version 8 if and when that happens. Functionally, which API variant of the FileSystem.newFileSystem() API is used shouldn't matter in the context of this test case. However, if someone feels that I should switch to the newer available API, then please do let me know and I'll update the patch. -Jaikiran

3 21

jpackage with a single java property
by Alexander Scherbatiy 04 Mar '20

04 Mar '20

Hello, CSR for JEP 343: Packaging Tool [1] has description for option value which consists of a list of strings: "If an option value is otherwise a list of strings, they must separated by space characters. Since the shell would otherwise take them as separate arguments, the list must be quoted. " For example: --java-options -server --java-options "--ea -Dfoo=bar" What about a single java property which value contains space characters (-Dfoo="bar 2")? Should it be possible to pass it in the way: --java-options -Dfoo="bar 2" or the whole property should be quoted like: --java-options "-Dfoo='bar 2'" [1] https://bugs.openjdk.java.net/browse/JDK-8213087 Thanks, Alexander.

3 3

Need bug id to remove the explicit type argument in test class
by Vipin Sharma 04 Mar '20

04 Mar '20

Hi, My OCA has been processed recently and I want to start Contributing to OpenJDK. As a first fix, I would like to remove the explicit type argument in test class test/jdk/java/lang/Boolean/MakeBooleanComparable.java to fix one warning. The first line given below is the existing code and the second line is what I am changing it to. List<Boolean> list = new ArrayList<Boolean>(); List<Boolean> list = new ArrayList<>(); If this is not too small change to start with, could you please help me to create a bug id against this so that I can create a patch and share. Regards, Vipin

3 2

RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr
by Vipin Mv1 04 Mar '20

04 Mar '20

Hi All, Please find the below changes for the issue https://bugs.openjdk.java.net/browse/JDK-8129841. Apart from the requested changes, I have made additional changes to the Signature where ever I found it incorrect. Thanks Vipin M V diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c --- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -218,7 +218,7 @@ /* * Class: java_net_Inet4AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c --- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -413,7 +413,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. @@ -668,7 +668,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: isReachable0 - * Signature: ([bII[bI)Z + * Signature: ([BII[BII)Z */ JNIEXPORT jboolean JNICALL Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this, diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet4AddressImpl.c --- a/src/java.base/windows/native/libnet/Inet4AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -171,7 +171,7 @@ /* * Class: java_net_Inet4AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet6AddressImpl.c --- a/src/java.base/windows/native/libnet/Inet6AddressImpl.c Wed Feb 05 12:20:36 2020 -0300 +++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.c Tue Mar 03 15:32:21 2020 +0530 @@ -240,7 +240,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: getHostByAddr - * Signature: (I)Ljava/lang/String; + * Signature: ([B)Ljava/lang/String; * * Theoretically the UnknownHostException could be enriched with gai error * information. But as it is silently ignored anyway, there's no need for this. @@ -435,7 +435,7 @@ /* * Class: java_net_Inet6AddressImpl * Method: isReachable0 - * Signature: ([bII[bI)Z + * Signature: ([BII[BII)Z */ JNIEXPORT jboolean JNICALL Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,

2 1

RFC: JEP JDK-8208089: Implement C++14 Language Features
by Kim Barrett 04 Mar '20

04 Mar '20

I've submitted a JEP for (1) enabling the use of C++14 Language Features when building the JDK, (2) define a process for deciding and documenting which new features can be used or are forbidden in HotSpot code, (3) provide an initial list of permitted and forbidden new features. https://bugs.openjdk.java.net/browse/JDK-8208089

13 41