February 2019 - core-libs-dev

RFR: JDK-8218055: Use ToolProvider instead of AppRuntimeImageBuilder.
by Andy Herrick 25 Feb '19

25 Feb '19

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This enhancement removes the use of jdk.tools.jlink.internal.packager.AppRuntimeImageBuilder in favor of invoking jlink directly thru the ToolProvider interface, with associated code cleanup. [1] https://bugs.openjdk.java.net/browse/JDK-8218055 [2] http://cr.openjdk.java.net/~herrick/8218055/webrev.02 /Andy

4 9

JDK 13 RFR of JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes
by Joe Darcy 25 Feb '19

25 Feb '19

Hello, Internally jdeprscan initializes a set of strings of releases supporting deprecation with removal. Currently those releases are JDK 9 and subsequent values. The lists is explicitly initialized and must be updated at the start of a release, which adds to the maintenance cost of starting a new release. The update for JDK 13 was: --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 17:01:15 2018 +0100 +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Dec 13 19:06:11 2018 +0100 @@ -106,7 +106,7 @@ // Keep these updated manually until there's a compiler API // that allows querying of supported releases. final Set<String> releasesWithoutForRemoval = Set.of("6", "7", "8"); - final Set<String> releasesWithForRemoval = Set.of("9", "10", "11", "12"); + final Set<String> releasesWithForRemoval = Set.of("9", "10", "11", "12", "13"); final Set<String> validReleases; { Initializing the list more programmatically could avoid the need for an explicit update for the start of a release. Please review the patch below for the programmatic initialization: --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 15:17:42 2019 -0800 +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java Thu Feb 21 18:01:59 2019 -0800 @@ -45,6 +45,7 @@ import java.util.NoSuchElementException; import java.util.Set; import java.util.Queue; +import java.util.stream.IntStream; import java.util.stream.Stream; import java.util.stream.StreamSupport; import java.util.jar.JarEntry; @@ -106,7 +107,12 @@ // Keep these updated manually until there's a compiler API // that allows querying of supported releases. final Set<String> releasesWithoutForRemoval = Set.of("6", "7", "8"); - final Set<String> releasesWithForRemoval = Set.of("9", "10", "11", "12", "13"); + // Set.of("9", "10", "11", "12", "13"); + final Set<String> releasesWithForRemoval = Set.of(// "9", "10", "11", ... + IntStream.rangeClosed(9, Runtime.version().feature()) + .mapToObj(Integer::toString) + .toArray(String[]::new)); + final Set<String> validReleases; { Thanks, -Joe

4 4

How does jpackage search for modules?
by Tobias Oelgarte 25 Feb '19

25 Feb '19

I'm wondering how jpackage searches for modules. I tried to build a very simple example (using Build 17 of jpackage), but jpackage always claims that the module can't be found. ~$ ./jpackage create-image \ --output /data/projects/javam/de.asysgmbh.app.test/target/image \ --name test \ --main-class de.asysgmbh.app.test.Main \ --module de.asysgmbh.app.test \ --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules ~ $ Module de.asysgmbh.app.test does not exist. The modules directory contains the file "de.asysgmbh.app.test-1.0-SNAPSHOT.jar" including the module-info.class with the module named "de.asysgmbh.app.test". module de.asysgmbh.app.test { ... } The following works just fine: ~$ java \ --module-path /data/projects/javam/de.asysgmbh.app.test/target/modules \ --module de.asysgmbh.app.test/de.asysgmbh.app.test.Main -- Tobias Oelgarte Mail: tobias.oelgarte(a)gmail.com

2 2

JDK-6982173: Small problem causing thousands of wasted CPU hours
by Jan Peter Stotz 25 Feb '19

25 Feb '19

Hi, like many other I ran into bug JDK-698217 which is about AbstractSet.removeAll() and it's "aptitude" in wasting CPU time if you accidentally hit this bug. And there are hundred of developers hitting this bug every year. I simply don't understand why there was no progress in 8 years, on a severe performance issue (a removeAll method on an efficient set that can require O(n^2)!) caused by code that was written to speed-up the removeAll implementation. Which makes this bug worse is that it is triggered by the relative size of the current set compared to the collection passed as parameter. Therefore for most developers this means not to use this buggy function at all (once they realized how worse it is). IMHO there is a extreme simple workaround for avoiding this problem. The relevant part of the current implementation is as follows: if (size() > c.size()) { for (Object e : c) modified |= remove(e); } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } The problem is that the code in the first if block only makes sense if the collections passed as parameter implements the remove(Object o) method in an efficient way - this means with a complexity of less than O(n). Java currently has no way to identify Collection implementations that satisfy this property we should at least implement a workaround that prevents the Java developers form unexpected "damage". Which mean that the first if block should only be triggered if we are sure that it is faster than the second case (because removing an element from a Set is usually implemented efficiently). Therefore I would propose a patch that no only compare the size of the current set and the given collection but also makes sure that the given collection is a Set or a Map: if (size() > c.size() && (c instanceof Set || c instanceof Map) { for (Object e : c) modified |= remove(e); } else { .... Jan

7 16

RFR: JDK-8218681 : Windows exe's generated by jpackage have wrong info
by Alexander Matveev 25 Feb '19

25 Feb '19

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - User provided version was not display, because it was added as additional LANG_ENGLISH resource and Windows Explorer was displaying default one added during build as LANG_NEUTRAL. Fixed by adding/modifying version information as LANG_NEUTRAL resource. - Removed unused fields from WinLauncher.template. - Improved error handling for version swap. - Fixed debug build after JDK-8212091 by removing not needed code from #ifdef DEBUG. [1] https://bugs.openjdk.java.net/browse/JDK-8218681 [2] http://cr.openjdk.java.net/~almatvee/8218681/webrev.00/ Thanks, Alexander

2 1

Faulty Null-Check Suspected in ToolProvider
by Philipp Kunz 23 Feb '19

23 Feb '19

Hi, There has always been an implicit null-check for args by the for loop attempting to iterate but the check seems to be intended and wrong for the elements. See attached patch. >From the comment to args, "the command-line arguments for the tool", I guess it makes sense to conclude that these should not be allowed to be null, just like on a command line, but empty strings are be fine. Regards, Philipp

4 11

RFR: JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0
by Vicente Romero 22 Feb '19

22 Feb '19

Please review the simple patch to fix [1] at [2]. The patch is simply adding a comment to the API, (javadoc) to sync it with the implementation. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8219480 [2] http://cr.openjdk.java.net/~vromero/8219480/webrev.00/

2 4

[13] RFR 8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale
by Nishit Jain 22 Feb '19

22 Feb '19

Hi, Please review the fix for JDK-8209175 Bug: https://bugs.openjdk.java.net/browse/JDK-8209175 Webrev: http://cr.openjdk.java.net/~nishjain/8209175/webrev.03/ Issue: In CLDR 33 update, 'B' character has been added in date time patterns for Burmese locale, which is used to represent the day period. This character is not supported in DateTimeFormatter or SimpleDateFormat APIs, so an exception is thrown that an "unknown character is encountered" Fix: A workaround is added in which 'B' character appearing in CLDR date-time pattern is replaced with 'a' character and hence resolved with am/pm strings. This is based on the LDML specification given for 'B' character in which it falls back to 'a' character if it is not supported by any locale. Regards, Nishit Jain

3 2

can't create an image using jpackage and javafx
by Edoardo Panfili 22 Feb '19

22 Feb '19

Hi, I'm trying to create an image of an application that uses JavaFX on macOS The builds goes well but when I try to launch the application the result is "LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/workspace/asteroidi/Asteroids.app." the project is a single module and a single file application (with some resources) I try to explain how I build the package: $PATH_TO_J12/java --version openjdk 12 2019-03-19 OpenJDK Runtime Environment (build 12+32) OpenJDK 64-Bit Server VM (build 12+32, mixed mode, sharing) $PATH_TO_J12/javac --module-path $PATH_TO_FX -d mods/asteroidi $(find src/ -name "*.java") cp src/gioco/!(*.java) mods/asteroidi/gioco/ $PATH_TO_J12/java --module-path "$PATH_TO_FX:mods" -m asteroidi/gioco.Angoli all goes well, the application works correctly If I use jlink to build the package all works fine. $PATH_TO_J13/jpackage --version jpackage version 13-internal $PATH_TO_J13/jpackage create-image --output . --name Asteroids --main-class gioco.Angoli --module asteroidi --module-path $PATH_TO_FX_MODS:mods with a double click on the Asteroid application in finder nothing happens using "open Asteroids.app" from the terminal LSOpenURLsWithRole() failed with error -10810 for the file /Users/edoardo/Desktop/java-next/asteroidi/Asteroids.app. Reagards Edoardo

2 3

[13] RFR: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO
by Naoto Sato 21 Feb '19

21 Feb '19

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8218960 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8218960/webrev.00/ The CONFIG message was generated because CLDRCalendarDataProviderImpl was returning null for locales without region. Use "US" as the default region in such a case. Naoto

4 7