March 2017 - core-libs-dev

RFR: 8177449: (tz) Support tzdata2017b
by Ramanand Patil 30 Mar '17

30 Mar '17

Hi all, Please review the latest TZDATA integration (tzdata2017b) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

3 3

JDK 9 RFR of 8177526: BufferedReader readLine() javadoc does not match the implementation regarding EOF
by Brian Burkhalter 29 Mar '17

29 Mar '17

Please review this doc-only change at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8177526 Patch: http://cr.openjdk.java.net/~bpb/8177526/webrev.00/ Thanks, Brian

3 5

JDK 10 [New Enhancement] - Consistently use primitive hashCode() variants in Arrays.hashCode() for primitive arrays
by Christoph Dreis 29 Mar '17

29 Mar '17

Hey, I just noticed that the Arrays.hashCode() variants for arrays of primitive types could use the methods in Float, Boolean etc. instead of duplicating the code. Please find the patch below. What do you think? I'd be happy if this is picked up for JDK 10. Cheers, Christoph =========== PATCH ====================== diff --git a/src/java.base/share/classes/java/util/Arrays.java b/src/java.base/share/classes/java/util/Arrays.java --- a/src/java.base/share/classes/java/util/Arrays.java +++ b/src/java.base/share/classes/java/util/Arrays.java @@ -4456,8 +4456,7 @@ int result = 1; for (long element : a) { - int elementHash = (int)(element ^ (element >>> 32)); - result = 31 * result + elementHash; + result = 31 * result + Long.hashCode(element); } return result; @@ -4593,7 +4592,7 @@ int result = 1; for (boolean element : a) - result = 31 * result + (element ? 1231 : 1237); + result = 31 * result + Boolean.hashCode(element); return result; } @@ -4620,7 +4619,7 @@ int result = 1; for (float element : a) - result = 31 * result + Float.floatToIntBits(element); + result = 31 * result + Float.hashCode(element); return result; } @@ -4647,8 +4646,7 @@ int result = 1; for (double element : a) { - long bits = Double.doubleToLongBits(element); - result = 31 * result + (int)(bits ^ (bits >>> 32)); + result = 31 * result + Double.hashCode(element); } return result; }

1 0

RFR: 8173871: Typos in Jar Packer/Unpacker PROGRESS field documentation
by Kumar Srinivasan 29 Mar '17

29 Mar '17

Hello, Please review fix for a typo. Thanks Kumar https://bugs.openjdk.java.net/browse/JDK-8173871 diff --git a/src/java.base/share/classes/java/util/jar/Pack200.java b/src/java.base/share/classes/java/util/jar/Pack200.java --- a/src/java.base/share/classes/java/util/jar/Pack200.java +++ b/src/java.base/share/classes/java/util/jar/Pack200.java @@ -458,8 +458,8 @@ * Progress can be monitored by polling the value of this * property. * - * At a minimum, the unpacker must set progress to 0 - * at the beginning of an unpacking operation, and to 100 + * At a minimum, the packer must set progress to 0 + * at the beginning of a packing operation, and to 100 * at the end. */ String PROGRESS = "pack.progress"; @@ -623,7 +623,7 @@ * property. * * At a minimum, the unpacker must set progress to 0 - * at the beginning of a packing operation, and to 100 + * at the beginning of an unpacking operation, and to 100 * at the end. */ String PROGRESS = "unpack.progress";

2 1

RFR: 8174148: Typo in java.util.jar.Pack200.Unpacker.properties() method documentation
by Kumar Srinivasan 29 Mar '17

29 Mar '17

Hello, Please review a fix for a simple typo. Thanks Kumar Bug: https://bugs.openjdk.java.net/browse/JDK-8174148 diff --git a/src/java.base/share/classes/java/util/jar/Pack200.java b/src/java.base/share/classes/java/util/jar/Pack200.java --- a/src/java.base/share/classes/java/util/jar/Pack200.java +++ b/src/java.base/share/classes/java/util/jar/Pack200.java @@ -631,7 +631,7 @@ /** * Get the set of this engine's properties. This set is * a "live view", so that changing its - * contents immediately affects the Packer engine, and + * contents immediately affects the Unpacker engine, and * changes from the engine (such as progress indications) * are immediately visible in the map. *

3 2

JDK 9 RFR of JDK-8177722: Improve grouping of jdk/internal/math tests
by joe darcy 29 Mar '17

29 Mar '17

Hello, The tests in jdk/internal/math tests test the floating decimal code which underlies the base conversion functionality used in the core libraries. This code is not part of BigInteger or BigDecimal and is not otherwise related to the java.math package. Therefore, the jdk/internal/math tests are better placed in the jdk_lang test group rather than jdk_math. Please review the patch below which moves the test group. Thanks, -Joe diff -r e685e3197f62 test/TEST.groups --- a/test/TEST.groups Mon Mar 27 18:38:58 2017 -0700 +++ b/test/TEST.groups Tue Mar 28 09:35:50 2017 -0700 @@ -73,6 +73,7 @@ jdk/internal/misc \ jdk/internal/ref \ jdk/internal/jimage \ + jdk/internal/math \ jdk/modules \ vm @@ -141,8 +142,7 @@ java/util/stream jdk_math = \ - java/math \ - jdk/internal/math + java/math jdk_io = \ java/io

2 1

Possible error in PackTestZip64.java!?
by Kharbas, Kishor 28 Mar '17

28 Mar '17

Hi! I came across an exception when running pack200 test PackTestZip64.java when I use a non-bundled zlib library with JDK8. This causes the test to fail. Upon examining the code, I believe the test fails incorrectly. The error is an side-effect of how new JarEntry's are created. Below is the detailed report : --------------------------------------------------------------------------------------------------------------------------------------------------- ERROR TITLE: PackTestZip64 fails incorrectly with ZipException with JDK using system zlib PRODUCT VERSION: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-root_2017_02_21_13_06-b00) OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode) OS VERSION: Linux kkharbas-desk2.amr.corp.intel.com 4.9.12-200.fc25.x86_64 #1 SMP Thu Feb 23 19:31:49 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux A DESCRIPTION OF THE PROBLEM: When using an alternative zlib implementation (in this case the implementation at https://github.com/jtkukunas/zlib) PackTestZip64 test fails incorrectly. The test fails with following exception: java.util.zip.ZipException: invalid entry compressed size (expected 88 but got 89 bytes) at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) at java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:109) at PackTestZip64.generateLargeJar(PackTestZip64.java:137) at PackTestZip64.testPacking(PackTestZip64.java:55) at PackTestZip64.main(PackTestZip64.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(Thread.java:745) Here is what happens : The test generates a new jar file ( in generateLargeJar()) from existing files in golden.jar and also adds a large number of small dummy files. Because the JarEntry is created from existing jar file, the compressed size for it is set. Later ZipOutputStream.closeEntry() validates the compressed size of a file by comparing it to number of bytes written, if (e.csize != def.getBytesWritten()) { throw new ZipException( "invalid entry compressed size (expected " + e.csize + " but got " + def.getBytesWritten() + " bytes)"); } The above check fails, throwing an exception. However, the Zlib specification gives implementations a flexibility of choosing a string search algorithm, thus generating different bit streams. A workaround is to reset the compressed size of 'JarEntry' before its added to the new jar. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. Build JDK specifying configure option : --with-zlib=system 2. Download and build the zlib from https://github.com/jtkukunas/zlib 3. Override the Linux zlib at /usr/lib64/ 4. Run PackTestZip64 test with jtreg --------------------------------------------------------------------------------------------------------------------------------------------------- If the community thinks this a valid diagnosis, an error should be filed. Thanks Kishor

1 1

RFR JDK-8177723: Suppress lint removal warning in java.se.ee and jdk.unsupported
by joe darcy 28 Mar '17

28 Mar '17

Hello, The java.se.ee module refers to the java.corba module, which is deprecated for removal. The jdk.unsupported module contains a use of Reflection.getCallerClass, which is deprecated for removal. The warnings associated with this code should be suppressed. Please review the associated changes in the webrev: http://cr.openjdk.java.net/~darcy/8177723.0/ (This issue is a subtask of JDK-8177553: Address removal lint warnings in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; however, if that is not approved as part of rampdown 2, I'll push the associated changes to JDK 10.) Thanks, -Joe

3 2

RFR of JDK-8177682: Suppress removal warning for System.runFinalizersOnExit
by joe darcy 28 Mar '17

28 Mar '17

Hello, The implementation of the method System.runFinalizersOnExit uses API elements that are deprecated for removal, namely Runtime.runFinalizersOnExit. System.runFinalizersOnExit is itself deprecated for removal. Until it is removed, the lint warning associated with using a deprecated for removal API should be suppressed. Please review the patch below to suppress this warning. (This issue is a subtask of JDK-8177553: Address removal lint warnings in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; however, if that is not approved as part of rampdown 2, I'll push the associated changes to JDK 10.) Thanks, -Joe diff -r fb54b256d751 src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.java Mon Mar 27 15:12:01 2017 -0700 +++ b/src/java.base/share/classes/java/lang/System.java Mon Mar 27 17:47:08 2017 -0700 @@ -1738,6 +1738,7 @@ * @since 1.1 */ @Deprecated(since="1.2", forRemoval=true) + @SuppressWarnings("removal") public static void runFinalizersOnExit(boolean value) { Runtime.runFinalizersOnExit(value); }

3 2

JDK 9 RFR of JDK-8177678: Overstatement of universality of Era.getDisplayName() implementation
by joe darcy 27 Mar '17

27 Mar '17

Hello, Please review the patch below to fix JDK-8177678: Overstatement of universality of Era.getDisplayName() implementation For background, the javadoc for Era.getDisplayName() states wishfully that "This default implementation is suitable for all implementations." Since in JDK 9 it was necessary to add an override for this method (JDK-8054214), the exaggerated claim of universality should be removed or amended. The patch weakens the statement of universality and moves it to an @implSpec tag. Since @implSpec tags are not inherited, the copy-and-paste of the documentation in the overridden method can be avoided. (Since this is a doc-only change, it does not have to go through the JDK 9 ramp down 2 approval procedures.) Thanks, -Joe diff -r 824789db6bea src/java.base/share/classes/java/time/chrono/Era.java --- a/src/java.base/share/classes/java/time/chrono/Era.java Fri Mar 24 16:35:51 2017 +0000 +++ b/src/java.base/share/classes/java/time/chrono/Era.java Mon Mar 27 15:49:12 2017 -0700 @@ -310,8 +310,8 @@ * The parameters control the style of the returned text and the locale. * * If no textual mapping is found then the {@link #getValue() numeric value} is returned. - * - * This default implementation is suitable for all implementations. + * + * @apiNote This default implementation is suitable for most implementations. * * @param style the style of the text required, not null * @param locale the locale to use, not null diff -r 824789db6bea src/java.base/share/classes/java/time/chrono/JapaneseEra.java --- a/src/java.base/share/classes/java/time/chrono/JapaneseEra.java Fri Mar 24 16:35:51 2017 +0000 +++ b/src/java.base/share/classes/java/time/chrono/JapaneseEra.java Mon Mar 27 15:49:12 2017 -0700 @@ -240,18 +240,10 @@ } /** - * Gets the textual representation of this era. - * - * This returns the textual name used to identify the era, - * suitable for presentation to the user. - * The parameters control the style of the returned text and the locale. - * - * If no textual mapping is found then the {@link #getValue() numeric value} - * is returned. + * {@inheritDoc} * - * @param style the style of the text required, not null - * @param locale the locale to use, not null - * @return the text value of the era, not null + * @param style {@inheritDoc} + * @param locale {@inheritDoc} * @since 9 */ @Override

3 3