September 2018 - core-libs-dev

RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero from java.text.DecimalFormat.format()
by Nasser Ebrahim 27 Sep '18

27 Sep '18

Hello, In java.text.DecimalFormat.format(), there is a validation to check whether a number is negative zero or not and for that divide by zero is used to check for negative infinity which caused the ArithmeticException when SIGFPE is enabled in the system. Andrew has opened a bug on my behalf. Thank you Andrew. The corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8211161. The webrev and stand alone test case is uploaded to http://cr.openjdk.java.net/~aleonard/8211161/. The recreate step is documented in the bug description. I have tested the fix with the test cases of the following bugs and confirm that it is working. https://bugs.java.com/view_bug.do?bug_id=4106658 https://bugs.java.com/view_bug.do?bug_id=4106667 https://bugs.java.com/view_bug.do?bug_id=4147706 I did not add any new jtreg test for the current issue as it is not functional. Hope that is fine. Kindly request you to review and comment. Thank you, Nasser Ebrahim

3 5

RFR; 8211031: Remove un-needed qualified export to java.desktop from java.base on macos
by Philip Race 27 Sep '18

27 Sep '18

Bug: https://bugs.openjdk.java.net/browse/JDK-8211031 webrev: http://cr.openjdk.java.net/~prr/8211031/ Removing some obsolete code which is the reason for a qualified export from java.base to java.desktop. I also cleaned up some commented out debugging code. See the bug evaluation for more details. -phil.

4 5

[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-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization
by Lance Andersen 26 Sep '18

26 Sep '18

Hi all: JDK-8211121 removes sun.reflect.ReflectionFactory::newInstanceForSerialization which was only used by the java.corba module. It was missed as part of the initial removal of the Java EE modules. The diff for the change: ————— s$ hg diff src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java diff -r a6bdb6d5f167 src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java --- a/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java Tue Sep 25 11:31:55 2018 -0700 +++ b/src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java Tue Sep 25 17:32:48 2018 -0400 @@ -145,66 +145,6 @@ } /** - * Invokes the supplied constructor, adding the provided protection domains - * to the invocation stack before invoking {@code Constructor::newInstance}. - * If no {@linkplain System#getSecurityManager() security manager} is present, - * or no domains are provided, then this method simply calls - * {@code cons.newInstance()}. Otherwise, it invokes the provided constructor - * with privileges at the intersection of the current context and the provided - * protection domains. - * - * @param cons A constructor obtained from {@code - * newConstructorForSerialization} or {@code - * newConstructorForExternalization}. - * @param domains An array of protection domains that limit the privileges - * with which the constructor is invoked. Can be {@code null} - * or empty, in which case privileges are only limited by the - * {@linkplain AccessController#getContext() current context}. - * - * @return A new object built from the provided constructor. - * - * @throws NullPointerException if {@code cons} is {@code null}. - * @throws InstantiationException if thrown by {@code cons.newInstance()}. - * @throws InvocationTargetException if thrown by {@code cons.newInstance()}. - * @throws IllegalAccessException if thrown by {@code cons.newInstance()}. - */ - public final Object newInstanceForSerialization(Constructor<?> cons, - ProtectionDomain[] domains) - throws InstantiationException, InvocationTargetException, IllegalAccessException - { - SecurityManager sm = System.getSecurityManager(); - if (sm == null || domains == null || domains.length == 0) { - return cons.newInstance(); - } else { - JavaSecurityAccess jsa = SharedSecrets.getJavaSecurityAccess(); - PrivilegedAction<?> pea = () -> { - try { - return cons.newInstance(); - } catch (InstantiationException - | InvocationTargetException - | IllegalAccessException x) { - throw new UndeclaredThrowableException(x); - } - }; // Can't use PrivilegedExceptionAction with jsa - try { - return jsa.doIntersectionPrivilege(pea, - AccessController.getContext(), - new AccessControlContext(domains)); - } catch (UndeclaredThrowableException x) { - Throwable cause = x.getCause(); - if (cause instanceof InstantiationException) - throw (InstantiationException) cause; - if (cause instanceof InvocationTargetException) - throw (InvocationTargetException) cause; - if (cause instanceof IllegalAccessException) - throw (IllegalAccessException) cause; - // not supposed to happen - throw x; - } - } - } - - /** * Returns a direct MethodHandle for the {@code readObjectNoData} method on * a Serializable class. * The first argument of {@link MethodHandle#invoke} is the serializable —————— Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com <mailto:Lance.Andersen@oracle.com>

4 5

Re: [CAUTION] [XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID after failing SetupI18nProps call [windows]
by Schmidt, Lutz 26 Sep '18

26 Sep '18

Hi Matthias, your change looks good. Please note that I'm not a reviewer! I have a suggestion you might want to think about: Why don't you move the free-loop outside the if-else? Except for the NULL check, it's the same code in both branches. Thanks for fixing! Lutz On 26.09.18, 16:30, "core-libs-dev on behalf of Baesken, Matthias" <core-libs-dev-bounces(a)openjdk.java.net on behalf of matthias.baesken(a)sap.com> wrote: Hello, could you please review this small change (windows only) ? Currently, the function "getJavaIDFromLangID" (located in windows java_props_md.c) only does proper deallocations after a successful call to the function SetupI18nProps. See if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT), &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]), &(elems[4]))) { ...... for (index = 0; index < 5; index++) { free(elems[index]); } However a failing call (SetupI18nProps returning false) might still need deallocations, because the function SetupI18nProps can malloc memory in the failing case as well . The change initializes the pointers in char * elems[5]; And later frees them in case they are not NULL . Webrev and bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webrev/ https://bugs.openjdk.java.net/browse/JDK-8211149 Best regards, Matthias

1 0

[12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values
by Naoto Sato 25 Sep '18

25 Sep '18

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8210633 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8210633/webrev.00/ As the submitter pointed out, the overload method that takes Chronology needs to be overridden in the anonymous DateTimeTextProvider class. Naoto

3 4

RFR: JDK-8197398 (zipfs) OutOfMemoryError when talking contents of empty JAR file
by Deepak Kejriwal 25 Sep '18

25 Sep '18

Hi all, Please help review the changes for JDK-8199776 to JDK8u:- Master Bug: https://bugs.openjdk.java.net/browse/JDK-8199776 Webrev: http://cr.openjdk.java.net/~rpatil/8199776/webrev.00/ Background:- We have bug JDK-8197398 fixed in jdk 12 where Files.walkFileTree walk indefinitely while processing JAR file with "/" as a directory inside. Since code for zipfs in jdk8dev different compared to jdk 12, the fix is not exactly same. Proposed fix: While iterating over the zip entries added a check to see if entry name is equal to "/" (absolute path). If the entry name is equal to "/" we don't add it to "inodes" map. Regards, Deepak

2 2

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

JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method
by joe darcy 24 Sep '18

24 Sep '18

Hello, Since enum types were added in JDK 5, which shipped GA in 2004, the javadoc for the compiler-generated static values() method for enums has stated: > Returns an array containing the constants of this enum type, in the > order they are declared. This method may be used to iterate over the > constants as follows: > > for (RoundingMode c : RoundingMode.values()) > System.out.println(c); While the tip to use the enhanced for loop to iterate over the constants of the enum type may have been reasonable to include in 2004, IMO it is unnecessary and clutter in 2018. Therefore, please review the changes for JDK-8173730: Stop including enhanced for-loop tip for enum values() method http://cr.openjdk.java.net/~darcy/8173730.0/ to remove the generation of the for loop tip. Patch below. Docs builds complete successfully and elides the tip as expected. Thanks, -Joe --- old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 2018-09-24 14:31:57.943000000 -0700 +++ new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 2018-09-24 14:31:57.771000000 -0700 @@ -230,12 +230,7 @@ #Documentation for Enums doclet.enum_values_doc.fullbody=\ Returns an array containing the constants of this enum type, in\n\ - the order they are declared. This method may be used to iterate\n\ - over the constants as follows:\n\ - <pre>\n\ - for ({0} c : {0}.values())\n\ -   System.out.println(c);\n\ - </pre> + the order they are declared. doclet.enum_values_doc.return=\ an array containing the constants of this enum type, in the order they are declared

2 1

RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList
by Daniel D. Daugherty 24 Sep '18

24 Sep '18

Greetings, The following bug was used to ProblemList a couple of tests: JDK-8209018 ProblemList tests affected by JDK-8208690 https://bugs.openjdk.java.net/browse/JDK-8209018 Jon's fix for JTREG has been in a promoted JTREG build for a while now so it's time to remove those tests from the ProblemList. Here's the subtask bug to remove the tests from the ProblemList: JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList https://bugs.openjdk.java.net/browse/JDK-8209019 Here's the diff: $ hg diff diff -r 6c17cf410d7c test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Mon Sep 24 12:18:51 2018 -0400 +++ b/test/jdk/ProblemList.txt Mon Sep 24 12:49:53 2018 -0400 @@ -559,9 +559,6 @@ java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all -java/net/Socket/LingerTest.java 8208690 generic-all -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all - ############################################################################ # jdk_nio Thanks, in advance, for any questions, comments or suggestions. Dan

3 4