September 2018 - core-libs-dev

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: 8210766: Remove obsolete qualified export sun.net.www to java.desktop
by Phil Race 14 Sep '18

14 Sep '18

bug : https://bugs.openjdk.java.net/browse/JDK-8210766 The sun.applet implementation was removed a few days ago, see http://hg.openjdk.java.net/jdk/client/rev/26a17d160081 This removed AppletClassLoader which consumed a class in sun.net.www and thus needed a qualified export to java.desktop from java.base. Now we don't need that qualified export any more .. so trivial diff below : diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java --- a/src/java.base/share/classes/module-info.java +++ b/src/java.base/share/classes/module-info.java @@ -234,7 +234,6 @@ jdk.jconsole, java.net.http; exports sun.net.www to - java.desktop, java.net.http, jdk.jartool; exports sun.net.www.protocol.http to -phil.

2 1

RFR(M) : 8210732 : remove jdk.testlibrary.Utils
by Igor Ignatyev 14 Sep '18

14 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html > 478 lines changed: 3 ins; 319 del; 156 mod; Hi all, could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class? webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html testing: tier[1-3] + :jdk_svc,:jdk_security_infra JBS: https://bugs.openjdk.java.net/browse/JDK-8210732 Thanks, -- Igor

3 3

[12] RFR:8210490:TimeZone.getDisplayName given Locale.US doesn't always honor the Locale
by Rachna Goel 14 Sep '18

14 Sep '18

Hi, Kindly review fix to JDK-8210490. Bug: https://bugs.openjdk.java.net/browse/JDK-8210490 Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/ This is a regression caused by JDK-8202537, where for timezones such as Etc/GMT-5, display names got formatted according to default locale. Fix is to specify locale, which was specified in timezone.getDisplayName() method. -- Thanks, Rachna

2 1

JDK-8124977: deadlock between engineers? (cmdline encoding challenges on Windows)
by Anthony Vanelverdinghe 14 Sep '18

14 Sep '18

Hi What is the status of this issue [1]? It addresses some long-standing issues with Java's Unicode support on Windows and was contributed by a team of Microsoft engineers. However, it seems to have gone dormant right before the finish line, and I can't really figure out who's waiting for whom at this point. A little reconstruction from what I could find: In January 2015, Martin Sawicki made the initial proposal to address the cmdline encoding challenges on Windows [2] >From June to September, there were ongoing discussions [3][4][5][6] In November, this was shortly picked up again by the Oracle engineers [7] In January 2016, after a ping by a Microsoft engineer, the discussions restarted [8] In February 2016, the patch seemed nearly ready for integration, with an Oracle engineer asking whom to mention as contributors etc. [9] Since then, I was unable to find any messages related to this issue (Personally, I would love to see this issue progress, in order to be able to associate Java programs with file extensions on Windows. This is currently problematic, since a file containing Unicode characters will not get passed correctly as an argument to the Java program) Kind regards, Anthony [1] https://bugs.openjdk.java.net/browse/JDK-8124977 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031068.ht… [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034226.html [4] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034488.html [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034838.html [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035466.… [7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036769.h… [8] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037927.ht… [9] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039013.h…

2 3

RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation
by Severin Gehwolf 14 Sep '18

14 Sep '18

Hi, Cross-posting this review-thread on core-libs-dev and build-dev as this is a build change, but affects fdlibm which is core-libs. With JDK-8170153 optimization for fdlibm code has been turned on for ppc64 s390 and aarch64. This patch intends to turn it on on all arches on Linux. I've not observed any precision issues. Is there a good reason to not use -O3 -ffp-contract=off everywhere? Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/ Testing: - java/lang/Math, java/lang/StrictMath tests (all pass). - Currently running through submit repo. A simple micro benchmark from JDK-8170153[1] shows these numbers for StrictMath: Function | before | after ---------------------------------------------- sin | 0m33.382s | 0m18.731s cos | 0m31.562s | 0m18.796s tan | 0m33.657s | 0m21.093s atan | 0m5.714s | 0m4.902s log | 0m6.212s | 0m4.439s log10 | 0m7.946s | 0m5.543s sqrt | 0m0.481s | 0m0.449s cbrt | 0m5.295s | 0m5.214s tanh | 0m1.404s | 0m1.307s log1p | 0m6.457s | 0m5.131s IEEEremainder | 0m10.629s | 0m6.048s atan2 | 0m8.037s | 0m5.668s hypot | 0m2.171s | 0m2.147s Thoughts? Thanks, Severin

8 43

[8u-dev] Request for review and approval for 8193830: Xalan Update: Xalan Java 2.7.2
by Aleks Efimov 14 Sep '18

14 Sep '18

Hello, Can I, please, have an approval to backport JDK-8193830 to jdk8u-dev? Webrev: http://cr.openjdk.java.net/~aefimov/8193830 JBS: https://bugs.openjdk.java.net/browse/JDK-8193830 JDK11 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051230.h… JDK11 changeset: http://hg.openjdk.java.net/jdk/jdk/rev/0474300affbd The JAXP source changes part is identical (after reshuffling) to original JDK11 fix. The differences are in the regression test: a) Location of the regression test b) Address missing jaxp.library.JAXPTestUtilities in JDK8 Therefore, the test change requires review too. With Best Regards, Aleksei

1 0

Why static_jli for java/javaw on Windows?
by Magnus Ihse Bursie 14 Sep '18

14 Sep '18

On Windows, we compile two versions of libjli, one normal dynamic dll, and one static library *). Then when we create our launchers, we link with the normal, dynamic libjli for all launchers, except java.exe and javaw.exe, which are linked with the static library. The build system needs to do some elaborate dancing to support this odd behavior, which affects code quality negatively. I would therefore like to remove this special treatment of java.exe and javaw.exe. I've done some extensive amount of code archeology to try and determine where and how this was added. The only thing I can figure out is that it was this way in the old build system, in the initial load of OpenJDK. In jdk/make/java/main/java/Makefile, two comments might shed some light: # Statically link java to avoid the dependency on msvcr71.dll. and # Statically link java to avoid the dependency on jli.dll. Apparently, someone was trying to get rid of dll dependencies from java.exe. Why that would be desirable it does not say. Neither why this should not apply to all other launchers. (Perhaps there were not that many in these days?) Do anyone think this still seems relevant? Otherwise I'd like to get rid of this hack, and link java and javaw just like all the other launchers. /Magnus *) Yeah, we do other funky stuff with libjli on other platforms as well. But for now, I'm focusing on Windows.

4 6

RFR(S) 8190737: use unicode version of the canonicalize() function to handle long path on windows
by Calvin Cheung 13 Sep '18

13 Sep '18

bug: https://bugs.openjdk.java.net/browse/JDK-8190737 webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/ Please review this change for handling long path specified in the -Xbootclasspath/a on windows. Highlight of changes: - canonicalize_md.c it makes use of the unicode version of canonicalize (wcanonicalize) if the original path is >= MAX_PATH. - zip_util.c it uses the unicode version of CreateFile (CreateFileW) if the original path is >= MAX_PATH. - io_util_md.c Since zip_util.c (libzip) calls the getPrefixed() function in canonicalize_md.c (libjava), the getPrefixed() function needs to be exported. - java_md.h The JVM_MAXPATHLEN has been increased from _MAX_PATH to 1024. It is because the the current usage of the canonicalize() function from vm code is to preallocate the output buffer as follows: char* canonical_path = NEW_RESOURCE_ARRAY_IN_THREAD(thread, char, JVM_MAXPATHLEN); if (!get_canonical_path(path, canonical_path, JVM_MAXPATHLEN)) { Also the unix version of canonicalize() function has the following check: int canonicalize(char *original, char *resolved, int len) { if (len < PATH_MAX) { errno = EINVAL; return -1; } So dynamically allocating the output buffer requires more work beyond the scope of this change. - LongBCP.java added a scenario to the test - a long path to a jar file in -Xbootclasspath/a. Testing: tier-[1,2,3]. thanks, Calvin

4 7

New candidate JEP: 343: Packaging Tool
by mark.reinhold＠oracle.com 13 Sep '18

13 Sep '18

http://openjdk.java.net/jeps/343 - Mark

1 0