November 2017 - core-libs-dev

RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map
by Stuart Marks 30 Nov '17

30 Nov '17

(also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map) Hi all, Here's an updated webrev for this changeset; the previous review thread is here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.… This webrev includes the following: * specification revisions to provide clearer definitions of "view" collections, "unmodifiable" collections, and "unmodifiable views" * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods * new Collectors.toUnmodifiableList, Set, and Map methods * tests for the new API methods I've added some assertions that require some independence between the source collection (or map) and the result of the copyOf() method. I've made a small but significant change to Set.copyOf compared to the previous round. Previously, it specified that the first of any equal elements was preserved. Now, it is explicitly unspecified which of any equals elements is preserved. This is consistent with Set.addAll, Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of which specify which of duplicate elements is preserved. (The outlier here is Stream.distinct, which specifies that the first element of any duplicates is preserved, if the stream is ordered.) I've also made some minor wording/editorial changes in response to suggestions from David Holmes and Roger Riggs. I've kept the wording changes that give emphasis to "unmodifiable" over "immutable." The term "immutable" is inextricably intertwined with "persistent" when it comes to data structures, and I believe we'll be explaining this forever if Java's "immutable" means something different from everybody else's. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8177290 add copy factory methods for unmodifiable List, Set, Map https://bugs.openjdk.java.net/browse/JDK-8184690 add Collectors for collecting into unmodifiable List, Set, and Map Thanks, s'marks

14 40

RFR(s): 8160406: Collection.toArray() spec should be explicit about returning precisely an Object[]
by Stuart Marks 30 Nov '17

30 Nov '17

Hi all, Please review this small spec change / clarification regarding Collection.toArray(). The runtime type of the array returned has always been intended to be exactly Object[] and not an array of some subtype. This requirement is actually implied by the spec already, but in the wrong place; the spec for <T> T[] toArray(T[] a) says > Note that toArray(new Object[0]) is identical in function to toArray(). Clearly, this should also be specified on toArray() itself. Patch is below. Thanks, s'marks diff -r 9bb771005928 -r c3d5e370e06f src/java.base/share/classes/java/util/Collection.java --- a/src/java.base/share/classes/java/util/Collection.java Tue Nov 28 17:14:30 2017 -0800 +++ b/src/java.base/share/classes/java/util/Collection.java Wed Nov 29 14:29:14 2017 -0800 @@ -268,7 +268,7 @@ * Returns an array containing all of the elements in this collection. * If this collection makes any guarantees as to what order its elements * are returned by its iterator, this method must return the elements in - * the same order. + * the same order. The returned array's component type is {@code Object}. * * <p>The returned array will be "safe" in that no references to it are * maintained by this collection. (In other words, this method must @@ -278,7 +278,8 @@ * <p>This method acts as bridge between array-based and collection-based * APIs. * - * @return an array containing all of the elements in this collection + * @return an array, whose component type is {@code Object}, containing all + * of the elements in this collection */ Object[] toArray();

3 5

RFR: 8189331 [testbug] java/io/Serializable/maskSyntheticModifier/MaskSyntheticModifierTest.java failed incorrect serialVersionUID
by Roger Riggs 30 Nov '17

30 Nov '17

Please review a test fix to copy the golden Foo.class into the classpath instead of the current directory. webrev: http://cr.openjdk.java.net/~rriggs/webrev-synthetic-8189331/ issue: https://bugs.openjdk.java.net/browse/JDK-8189331 Thanks, Roger

2 1

RFR JDK-8187910: Charset MS950_HKSCS not supported in JDK 9
by Xueming Shen 30 Nov '17

30 Nov '17

Hi Please help review the change for JDK-8187910. issue: https://bugs.openjdk.java.net/browse/JDK-8187910 webrev: http://cr.openjdk.java.net/~sherman/8187910/webrev The change is to add charset MS950_HKSCS into sun.nio.cs/"standard charset provider" on Windows platform. It appears it is being used for Windows7's Traditional, Hong Kong S.A.R. locale, as reported. Thanks, Sherman

2 1

[10] RFR 6354947: [Fmt-*] DecimalFormat ignores FieldPosition settings on input, contrary to Javadocs
by Nishit Jain 30 Nov '17

30 Nov '17

Hi, Please review the fix for JDK-6354947 Bug: https://bugs.openjdk.java.net/browse/JDK-6354947 Webrev: http://cr.openjdk.java.net/~nishjain/6354947/webrev.02/ CSR: https://bugs.openjdk.java.net/browse/JDK-8191014 Fix: Clarified handling of the FieldPosition settings in the java.text.Format APIs specification. Regards, Nishit Jain

3 3

RFR: JDK-8189611: JarFile versioned stream and real name support
by Xueming Shen 30 Nov '17

30 Nov '17

Hi, Please help review the change for JDK-8189611. issue: https://bugs.openjdk.java.net/browse/JDK-8189611 webrev: http://cr.openjdk.java.net/~sherman/8189611/webrev Notes: (1) To add three public methods to help iterating/streaming the versioned entries for multi-release jar file support (CSR is to be filed) JavaFile.versionedStream() JavaFile.getRealName() ZipFile.entryNameStream() -- a convenient method for use scenario that only the entry name is interested. (2) To update jdk code( jlink, module, loader, where currently the internal/private methods are used) to use the new public methods for "versionedStream()" and "getRealName()" need. (jdeps is not being updated for now as it is now compiled by boot jdk). (3) To cleanup the way how the JarFileEntry and its corresponding versioned one are searched and created. By pushing the JarFileEntry constructor into ZipFile via SharedSecrets, we are now using much less memory (almost half) for JarFileEntry creation and have a slightly faster iteration (around 10% by jmh simple benchmark). (4) To add a fast-path in ZipCoder for UTF8 charset+ascii-only entry name. To take the advantage of the compact String to remove the unnecessary char[] usage. This is related to JDK-8184947: ZipCoder performance improvements (5) Two snapshots of the JFR recording of the memory usages for simply looping the JarFile.stream() on old rt.jar for 60s, before and after the change of (3)/(4) http://cr.openjdk.java.net/~sherman/8189611/mem_before.png http://cr.openjdk.java.net/~sherman/8189611/mem_after.png Thanks, Sherman

5 14

RFR: jsr166 jdk10 integration wave 6
by Martin Buchholz 29 Nov '17

29 Nov '17

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ove… Thanks to Dávid Karnok and Pavel Rappo for help with SubmissionPublisher. 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw 8187947: A race condition in SubmissionPublisher 8191069: Miscellaneous changes imported from jsr166 CVS 2017-12

3 5

[10] RFR: 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class
by Aleks Efimov 29 Nov '17

29 Nov '17

Hi, Can I, please, ask for assistance with reviewing the JDK-8186441 fix [1]? Problem description: In JDK9 we've fixed SAAJ bug in JDK: https://bugs.openjdk.java.net/browse/JDK-8159058 And this fix caused JDK-8186441 regression that resulted in breaking the namespace definitions in SOAP elements, i.e. the namespace definitions were added to SOAP body or to the parent elements. I'm aware that we're going to remove JAXWS and other EE modules in JDK10, but I still would like to fix this bug since it is a regression in existing code and JDK8 backport is also required for this issue. Will submit the same source fix to saaj-ri project [2] too. Solution: Fix the implementation of SaajStaxWriter::DeferredElement to add namespaces declaration to current element instead of parent. Webrev: http://cr.openjdk.java.net/~aefimov/8186441/10/00/index.html Testing: Modified regression test and XML/JAXWS JCK tests show no failures with the fix With Best Regards, Aleksei [1] https://bugs.openjdk.java.net/browse/JDK-8186441 [2] https://github.com/javaee/metro-saaj

2 2

[10] RFR 8176841: Additional Unicode Language-Tag Extensions
by Naoto Sato 29 Nov '17

29 Nov '17

Hello, Please review the proposed changes for the following issues: 8176841: Additional Unicode Language-Tag Extensions 8189134: New system properties for the default Locale extensions The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8176841/webrev.03/ This serves as the implementation of JEP 314. Naoto

4 26

RFR: JDK-8186087: jar tool fails to create a multi-release jar when validating nested classes
by Xueming Shen 29 Nov '17

29 Nov '17

Hi Please help review the change for #8186087 Issue: https://bugs.openjdk.java.net/browse/JDK-8186087 webrev: http://cr.openjdk.java.net/~sherman/8186087/webrev The proposed change is to handle the "outer class" of a nested class correctly, instead of simply relying on "top level" class. Other than that, a "minor" change is to also stop trying to "validate" the non-class/resource entries, for example, if you have a resource "foo" both in the base and versioned directory, and with different "content", currently implementation throws a warning message, which does not appear to be desired and appropriate. There is a "known/open" issue during discussion regarding how to handle the entry that its class name does not match its entry name (for example, class p.foo.class is located at bar/p/foo.class, currently jar.validator fails the validation with error msg). It appears to be a separate issue, so I'm leaving that one of this one for now. Thanks, Sherman

2 1