August 2018 - core-libs-dev

[PATCH] JDK-7033681 - Improve the documentation of Arrays.asList
by Jaikiran Pai 27 Sep '18

27 Sep '18

Hello everyone, I'm requesting a review of a documentation change which was discussed in a recent thread[1][2]. Here's an initial proposed draft, for a better documentation of Arrays.asList method: /** * Returns a fixed-size list backed by the specified array. The passed * array is held as a reference in the returned list. Any subsequent * changes made to the array contents will be visible in the returned * list. Similarly any changes that happen in the returned list will * also be visible in the array. The returned list is serializable and * implements {@link RandomAccess}. * * <p>The returned list can be changed only in certain ways. Operations * like {@code add}, {@code remove}, {@code clear} and other such, that * change the size of the list aren't allowed. Operations like * {@code replaceAll}, {@code set}, that change the elements in the list * are permitted. * * <p>This method acts as bridge between array-based and collection-based * APIs, in combination with {@link Collection#toArray}. * * @apiNote * This method also provides a convenient way to create a fixed-size * list initialized to contain several elements: * <pre> * List<String> stooges = Arrays.asList("Larry", "Moe", "Curly"); * </pre> * * <p>The returned list throws a {@link UnsupportedOperationException} for * operations that aren't permitted. Certain implementations of the returned * list might choose to throw the exception only if the call to such methods * results in an actual change, whereas certain other implementations may * always throw the exception when such methods are called. * * @param <T> the class of the objects in the array * @param a the array by which the list will be backed * @return a list view of the specified array */ @SafeVarargs @SuppressWarnings("varargs") public static <T> List<T> asList(T... a) I've edited some of the existing documentation of that method, moved some existing parts into @apiNote and added additional parts both to the spec as well as the @apiNote. For a complete reference of what's changed, I've also attached a patch of this change. P.S: Is there a specific (make) target that I can run to make sure changes like this one haven't caused any javadoc generation issues? I typically run just "make" and did it this time too, but I'm not sure it parses and generates the javadocs (couldn't find it in the generated exploded build image). [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054894.html [2] https://bugs.openjdk.java.net/browse/JDK-7033681 -Jaikiran

4 18

RFR: JDK-8205461 Create Collector which merges results of two other collectors
by Tagir Valeev 25 Sep '18

25 Sep '18

Please review and sponsor: https://bugs.openjdk.java.net/browse/JDK-8205461 http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/ See also previous discussion thread at [1]. It seems that we did not reach the final conclusion about the collector name, so in this review it's still named as "pairing" (proposed by me). Other name proposals: bisecting - by Paul Sandoz (sounds like input is split by two parts like in partitioningBy, which is not the case) tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical operation, while our collector is symmetrical) duplex(ing) - by Jacob Glickman (well, probably ok?) bifurcate - by James Laskey (or bifurcating?) replicator - by James Laskey (as in DNA) replicating - by Peter Levart fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked Wikipedia [2], does not look like suitable) distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac; but common meaning of "distributing" is different) tapping - by Kirk Pepperdine (I have no associations; Google images shows some acupuncture procedures) split - by Kirk Pepperdine (may be confused with Spliterator) unzipping - by John Rose biMapping - by Zheka Kozlov (but he also suggests to change signature which is unnecessary) toBoth - by Peter Levart (but usually toXyz shows target container like toArray/toList/toSet, but there's not "Both" container) collectionToBothAndThen - by Zheka Kozlov (but too long) collectingToBoth - by Zheka Kozlov collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a little bit repititive?) biCollecting - by Zheka Kozlov expanding - by Paul Sandoz (doesn't sound very descriptive to me) forking - by Victor Williams Stafusa da Silva (could be thought that something is parallelized as forking is usually something connected to parallel computations) I think that it's better to concentrate not on the "splitting" part (each element is passed to two collectors), but on the "joining" part (results of two collectors are combined together). So my preference now is "merging" or "combining". If limiting the selection to the suggested options I'd prefer "duplexing" or "bifurcating" or to stay with my original version "pairing". Of course original Stream API author voices have more weight here, so if you insist on particular version, I will follow. By the way looking into CollectorsTest.java I found some minor things to cleanup: 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with simple `.map(mapper)` and `.flatMap(mapper)` respectively 2. In many methods redundant `throws ReflectiveOperationException` is declared while exception is never thrown 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks useless as `map` is already of `Map<Boolean, D>` type, so this check is always false (we would never enter this method if it's true). Similarly `if (!List.class.isAssignableFrom(value.getClass()))` 4. Deprecated `clazz.newInstance()` is used 5. Test named `testGroupubgByWithReducing` should be renamed to `testGroupingByWithReducing` Should I fix some or all of these issues? As separate changeset or within this one? With best regards, Tagir Valeev. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html [2] https://en.wikipedia.org/wiki/Fan-out

8 29

API for parsing path strings
by Roger Riggs 14 Sep '18

14 Sep '18

Hi, Parsing of paths such as the values of properties java.class.path and java.library.path do not have direct support in the Java API. There are several implementations within OpenJDK and a few variations exist with regard to treatment of empty path elements and on Windows support for quoting. Would it be useful to have an API such as the following: /** * Returns a list of paths parsed from a string separated by {@link File#pathSeparator}. * All characters except the {@link File#pathSeparator} are allowed. * Some operating systems support quoting segments of the string * potentially including {@code pathSeparator} characters. * Empty paths, identified by leading, trailing, and adjacent separator characters, * can be omitted or replaced with a non-null provided path. * * @implNote * On Windows, zero or more characters between double-quotes ({@code "}) are included * literally in the path, regardless of whether they are valid in a path. * * @param path a string containing paths separated by the {@link File#pathSeparator} * @param emptyPath a path to replace an empty path or {@code null} to ignore empty paths * @return an immutable list of strings for each path; {@code non-null} */ public static List<String> parsePathStrings(String path, String emptyPath) { ...} There are of course, possible variations and convenience versions but the API should be kept to the essentials. With java.util.streams it becomes easy to process each component or to map the strings to Files or Path. Suggestions welcome, Roger

12 38

RFR JDK-8209553: ExceptionInInitializerError can have a default detail message if the cause is given
by mandy chung 13 Sep '18

13 Sep '18

ExceptionInInitializerError(Throwable cause) sets the detail message to null. It'd be helpful to include a detail message rather than null as in Throwable(Throwable cause) that constructs a new throwable with a default message cause==null ? null : cause.toString(). This would help troubleshooting of writing new bootstrap methods where VM currently asserts non-null linkage error message [1] where there are other solutions such as constructing the message in the VM or removing the assert. This patch proposes to change ExceptionInInitializerError(Throwable cause) to default the detail message to cause.toString() if cause is not null. It's an incompatibility change; for example existing code that expects a null message will now see a detail message. But the compatibility risk should be low as EIIE should be fatal. This also proposes to add new LinkageError(Throwable cause) constructor to retrofit the exception chaining mechanism and that allows to clean up the current ExceptionInInitializerError implementation. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8209553/webrev.00 I will create a CSR. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8208172

6 19

RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock
by Roger Riggs 13 Sep '18

13 Sep '18

Please review changes for: 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock Use System.nanoTime to compute any remaining delay 8210004: Thread.sleep(millis, nanos) timeout returns early Avoid an early return by rounding the milliseconds up if there are any nanoseconds as was done in Object.wait(ms, ns). (If its not appropriate to do the two reviews together, I can split them). Webrev: http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ Thanks, Roger

3 7

[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
by Baesken, Matthias 12 Sep '18

12 Sep '18

Hello, please review this small change that improve exception messages during manifest parsing of jar archives . Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8205525 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525/

9 73

RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection
by vyom tewari 11 Sep '18

11 Sep '18

Hi All, Please review this simple fix below webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html bugid: https://bugs.openjdk.java.net/browse/JDK-8205330 This fix will resolve the race in LdapClient where we are explicitly making "null" to LdapClient.conn. Thanks, Vyom

3 13

[12] RFR 8209773: Refactor shell test javax/naming/module/basic.sh to java
by Chris Yin 11 Sep '18

11 Sep '18

Please have a review for below change to refactor shell test javax/naming/module/basic.sh to plain java, no test logic change, old shell script is removed at same time, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8209773 webrev: http://cr.openjdk.java.net/~xyin/8209773/webrev.00/ Regards, Chris

3 6

RFR - JDK-8200434 - String::align, String::indent (code review)
by Jim Laskey 06 Sep '18

06 Sep '18

Please review the code for String::align and String::indent at the link below. Notes: Includes a private version of String::isMultiline() which may be made into a public method at some future date Includes minor correctness clean up of StringLatin1.java, StringUTF16.java webrev: http://cr.openjdk.java.net/~jlaskey/8200434/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8200434 Cheers, — Jim

3 4

RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
by Andrew Leonard 06 Sep '18

06 Sep '18

Hi, We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's default compiler options has highlighted a couple of native code issues, with undefined behaviours: - validating loop test array bounds - left shifts of negative values I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 and attached the webrev fix here: http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ This has already been discussed and refined on the "s390x-port-dev" maillist and as it was pointed out, it should have been posted here... I'd like to request a sponsor for this fix please? Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

5 17