April 2020 - core-libs-dev

RFR(T) : 8244066 : ClassFileInstaller should be run in driver mode
by Igor Ignatyev 29 Apr '20

29 Apr '20

http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00 > 16 lines changed: 0 ins; 0 del; 16 mod; Hi all, could you please review this trivial cleanup in tests? from JBS: > ClassFileInstaller is a test utility class which copies class files to the current directory, there is no point in running it w/ external flags, hence it should be run in a driver mode. testing: updated tests webrev: http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8244066 Thanks, -- Igor

3 4

[XXS] JDK-8243598: Typos in java.lang.invoke package-info
by Mandy Chung 29 Apr '20

29 Apr '20

diff --git a/src/java.base/share/classes/java/lang/invoke/package-info.java b/src/java.base/share/classes/java/lang/invoke/package-info.java --- a/src/java.base/share/classes/java/lang/invoke/package-info.java +++ b/src/java.base/share/classes/java/lang/invoke/package-info.java @@ -31,7 +31,7 @@ * As described in the Java Virtual Machine Specification, certain types in this package * are given special treatment by the virtual machine: * <ul> - * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle} + * <li>The classes {@link java.lang.invoke.MethodHandle MethodHandle} and * {@link java.lang.invoke.VarHandle VarHandle} contain * <a href="MethodHandle.html#sigpoly">signature polymorphic methods</a> * which can be linked regardless of their type descriptor. @@ -190,7 +190,7 @@ * invoked with just the parameter types of static arguments, thereby supporting a wider * range of methods compatible with the static arguments (such as methods that don't declare * or require the lookup, name, and type meta-data parameters). - * <p> For example, for dynamically-computed call site, a the first argument + * <p> For example, for dynamically-computed call site, the first argument * could be {@code Object} instead of {@code MethodHandles.Lookup}, and the return type * could also be {@code Object} instead of {@code CallSite}. * (Note that the types and number of the stacked arguments limit Mandy

3 2

RFR: JDK-8243673: Mac signing process should not use --deep arg.
by Andy Herrick 28 Apr '20

28 Apr '20

Please review webrev at [1] to address issue [2]. /Andy [1] - http://cr.openjdk.java.net/~herrick/8243673/webrev.01/ [2] - https://bugs.openjdk.java.net/browse/JDK-8243673

3 2

RFR: 8242541: Small charset issues (ISO8859-16, x-eucJP-Open, x-IBM834 and x-IBM949C)
by Ichiroh Takiguchi 28 Apr '20

28 Apr '20

Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8242541 Change: https://cr.openjdk.java.net/~itakiguchi/8242541/webrev.00/ I applied following changes: * Missing historical name alias in ISO8859-16 * Typo hisname on x-eucJP-Open * x-IBM834 and x-IBM949C charset source codes should be template style I appreciate your feedback and suggestions. Thanks, Ichiroh Takiguchi IBM Japan, Ltd.

2 3

RFR: 8243648: Windows 32bit compile error src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp
by Baesken, Matthias 28 Apr '20

28 Apr '20

Hello, please review this small fix for the windows 32bit build . Currently we run into this compile error on Windows : ./src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp(123): error C2220: warning treated as error - no 'object' file generated ./src/jdk.incubator.jpackage/windows/native/libjpackage/VersionInfo.cpp(123): warning C4244: 'argument': conversion from 'std::streamoff' to 'size_t', possible loss of data (after 8236129 was pushed) On windows 32bit we have typedef long streamoff according to https://docs.microsoft.com/en-us/cpp/standard-library/ios-typedefs?view=vs-… so we had issues with the size_t conversion . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8243648 http://cr.openjdk.java.net/~mbaesken/webrevs/8243648.0/ Thanks, Matthias

3 2

RFR(S) 8241815: Unnecessary calls to SystemDictionaryShared::define_shared_package
by Calvin Cheung 28 Apr '20

28 Apr '20

JBS: https://bugs.openjdk.java.net/browse/JDK-8241815 webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/ This change is to avoid java up call of definePackage() while loading a shared app/platform class originated from the module image since the packages from module image are already created during VM bootstrap in Module::define_module(). (including core-libs-dev since the change removes two methods in jdk/internal/loader/ClassLoaders.java) Testing: tier1 - 4. thanks, Calvin

4 5

jpackage -- icon setting for packages dmg/exe
by jjk 27 Apr '20

27 Apr '20

Tried various forms of --icon Iconfile.icns --resource-folder folder_name etc, but 'am still getting default images for dmg and app (java snowman) and same for windows version jdk. What is the right way to change this behavior of jpackage (tried both open jdk-15 EA and Jdk-14.1) Thanks in advance. --JJK -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html

2 5

[15] RFR: 8243664: JavaDoc of CompactNumberFormat points to wrong enum
by naoto.sato＠oracle.com 27 Apr '20

27 Apr '20

Hello, Please review this small doc fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8243664 Here is the diff: --- --- old/src/java.base/share/classes/java/text/CompactNumberFormat.java 2020-04-27 09:09:14.000000000 -0700 +++ new/src/java.base/share/classes/java/text/CompactNumberFormat.java 2020-04-27 09:09:14.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -206,7 +206,7 @@ * {@link java.math.RoundingMode} for formatting. By default, it uses * {@link java.math.RoundingMode#HALF_EVEN RoundingMode.HALF_EVEN}. * - * @see CompactNumberFormat.Style + * @see NumberFormat.Style * @see NumberFormat * @see DecimalFormat * @since 12 --- javadoc is clever enough to convert it to correct NumberFormat.Style link, but still this should be corrected. Naoto

3 2

RFR: 8243469: Lazily encode name in ZipFile.getEntryPos
by Claes Redestad 27 Apr '20

27 Apr '20

Hi, current implementation of ZipFile.getEntryPos takes the encoded byte[] of the String we're looking up. Which means when looking up entries across multiple jar files, we allocate the byte[] over and over for each jar file searched. If we instead refactor the internal hash table to use a normalized String-based hash value, we can almost always avoid both the repeated encoding and (most of) the hash calculation when the entry is not found in the jar/zip. This realizes a significant startup improvement on applications with several or many jar files. A rather typical case. For example I see a 25% speedup of ZipEnty.getEntry calls on a Spring PetClinic, which reduces total startup time by ~120ms, or ~2.5% of total, on my setup. At the same time remaining neutral on single-jar apps. Webrev: http://cr.openjdk.java.net/~redestad/8243469/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8243469 Testing: tier1-2 Thanks! /Claes

3 9

RFR (T): 8242846: Bring back test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java (was: Re: RFR (T): 8242846: removed an empty file test/jdk/tools/jlink/plugins/OrderResourcesPluginTest.java)
by Ao Qi 27 Apr '20

27 Apr '20

On Sun, Apr 26, 2020 at 12:00 AM Alan Bateman <Alan.Bateman(a)oracle.com> wrote: > > On 21/04/2020 04:58, Ao Qi wrote: > > > > On 2020/4/20 下午9:27, Alan Bateman wrote: > >> On 20/04/2020 11:32, sundararajan.athijegannathan(a)oracle.com wrote: > >>> Hi Alan, > >>> > >>> I don't remember it now. Likely a mistake. The changeset > >>> > >>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a066fe7b1b42 > >>> > >>> has that file. Perhaps it may be useful to restore & check if the > >>> test passes. > >> Yes. I think it was the only test for this jlink option so let's > >> bring it back or replace it. > >> > > > > I think the test should be brought back. I restored the test and it > > didn't pass. Here is the diff against the original test[1]: > > http://cr.openjdk.java.net/~aoqi/8242846/diff.01, and the new webrev > > is http://cr.openjdk.java.net/~aoqi/8242846/webrev.01/ . I'm not > > familiar with this field, so I am not sure I fix this rightly. > Thanks, I think this looks okay. Thanks, Alan. I have updated the bug title. Is another review needed? Cheers, Ao Qi > > -Alan.

2 4