April 2020 - core-libs-dev

RFR 8242860: test/jdk/tools/jlink/ModuleNamesOrderTest.java uses nashorn module
by sundararajan.athijegannathan＠oracle.com 17 Apr '20

17 Apr '20

Hi, nashorn modules were used only as an example in this test. Using jdk.jshell module instead to test known module dependencies in jlink produced images. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8242860 Webrev: http://cr.openjdk.java.net/~sundar/8242860/webrev.00/ Thanks, -Sundar

2 1

JDK-8160768: LdapDnsProviderService confined to application class loader
by Osipov, Michael 17 Apr '20

17 Apr '20

Folks, can some one, or Rob, explain why this class is explicitly tied to the application class loader [1] when using the ServiceLoader? Is there any specific implication when the thread context class loader is used? This makes it rather problematic using in a stacked class loader environment as Apache Tomcat [2]. I can neither put it in the webapp class path nor the common.loader class path although the caller is in common.loader. I have patched the class locally, recomplied OpenJDK 14 and it worked from both, application class loader and Tomcat's common.loader. Can someone explain this? Regards, Michael [1] https://github.com/AdoptOpenJDK/openjdk-jdk14u/blob/248c646c6e6c120b7d01acc… [2] https://www.mail-archive.com/users@tomcat.apache.org/msg134881.html

2 4

RFR 8242931: Few more tests that use nashorn have been missed
by sundararajan.athijegannathan＠oracle.com 17 Apr '20

17 Apr '20

Nashorn engine removal fix (8241749: Remove the Nashorn JavaScript Engine) missed updating few tests, config files. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8242931 Webrev: http://cr.openjdk.java.net/~sundar/8242931/webrev.00/ PS I'm disabling tests by adding @ignore. I've filed bugs for the tests. Please revisit port or remove these nashorn using tests Thanks, -Sundar

5 8

RFR: 8241055: Regex Grapheme Matcher Performance Depends too much on Total Input Sequence Size
by Philipp Kunz 16 Apr '20

16 Apr '20

Hi, Any opinions on the attached patch or someone tempted to sponsor it? Regards, Philipp

2 6

Re: jpackage and macOS Catalina notarization
by James Elliott 16 Apr '20

16 Apr '20

[Whoops, it seems that this list strips out image attachments, so my first attempt to send this message was pretty useless. Trying again, after uploading the screenshot to my web server so I can link to it instead.] Ok, thanks for clarifying that, I will drop my expectations for Catalina happiness for the moment, and perhaps can help make things work better when I have some time. Is there a pointer at how one gets vetted for submitting pull requests? Or I could just look at the source and post ideas here if that is better. For now, here is what a jpackage-created disk image looks like when I open it in Catalina: https://deepsymmetry.org/images/jpackage_dmg_screenshot.png The command that generates this is: https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scri… <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scri…> There are no errors reported during the build Cheers, -James > Date: Wed, 15 Jan 2020 14:54:55 +0100 > From: Michael Paus <mp(a)jugs.org <mailto:mp@jugs.org>> > To: core-libs-dev(a)openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> > Subject: Re: jpackage and macOS Catalina notarization > Message-ID: <84d90e7b-fbc8-4be5-09a2-56457edf4e23(a)jugs.org <mailto:84d90e7b-fbc8-4be5-09a2-56457edf4e23@jugs.org>> > Content-Type: text/plain; charset=utf-8; format=flowed > >> I also notice that the background image and Applications folder alias that are supposed to be in the disk image don?t seem to work in Catalina, so I may give up on having jpackage create my disk images as well, and do that using native tools, until that can be fixed. (I realize it is in early access still, and hope these issues are being worked on.) > > What exactly is wrong with the background image? Were there any build > errors reported during packaging? > > The creation of the disk image is done via some script and you can tell > jpackage via the > option --temp <some empty dir> to dump that into a temporary folder. You > can modify it > and place it into another folder which you tell jpackage via > --resource-dir <some dir with the modified script> > Maybe you can fix your issue that way or at least you can find out what > the problem is. > > I am still on the previous version of macOS until all these Catalina > issues are sorted out. > Java/JavaFX on Catalina is a mess right now.

2 2

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes
by Mandy Chung 16 Apr '20

16 Apr '20

On 4/16/20 11:42 AM, serguei.spitsyn(a)oracle.com wrote: > Hi Mandy, > > I have a couple of minor comments on the Serviceability spec update. > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.0… > > Replace: "The returned name is the same form as ..." => "The returned > name is of the same form as ..." > > > Example is: > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.0… > > + * Returns the name of this type. The result is of the same form as > > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.0… > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.0… > > Both files above have this: "a `class` file representation". > It feels like something is wrong with the `class` part. > Should it say `class file` or maybe use some other formatting? > > Otherwise, the Serviceability spec update looks great. > I'll look at the non-Serviceability spec changes too. Thanks for catching these typo/format issue. I have fixed them in my local repo: diff --git a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java @@ -391,7 +391,7 @@ * <p> * A class or interface creation can be triggered by one of the following: * <ul> - * <li>by loading and deriving a class from a `class` file representation + * <li>by loading and deriving a class from a {@code class} file representation * using class loader (see JVMS {@jvms 5.3}). * <li>by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) * Lookup::defineHiddenClass} that creates a {@link Class#isHidden diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ReferenceType.java @@ -85,7 +85,7 @@ { /** * Returns the name of this {@code ReferenceType} object. - * The returned name is the same form as the name returned by + * The returned name is of the same form as the name returned by * {@link Class#getName()}. * * @return a string containing the type name. diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java @@ -137,7 +137,7 @@ * <p> * A class or interface creation can be triggered by one of the following: * <ul> - * <li>by loading and deriving a class from a `class` file representation + * <li>by loading and deriving a class from a {@code class} file representation * using class loader (see JVMS {@jvms 5.3}). * <li>by invoking {@link java.lang.invoke.MethodHandles.Lookup#defineHiddenClass(byte[], boolean, java.lang.invoke.MethodHandles.Lookup.ClassOption...) * Lookup::defineHiddenClass} that creates a {@link Class#isHidden Mandy

1 0

RFR: 8242596: Improve JarFile.getEntry performance for multi-release jar
by Claes Redestad 16 Apr '20

16 Apr '20

Hi, please review this patch to improve JarFile.getEntry performance on multi-release jar files, mainly contributed by Eirik Bjørsnøs. The main idea is to piggy-back on the scanning of meta-inf entries we already do during initCEN to scan what versions exists in the jar file. This then reduces the number of lookups we'll have to do in typical scenarios. Webrev: http://cr.openjdk.java.net/~redestad/8242596/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8242596 Testing: tier1-2 Thanks! /Claes

2 3

Improving ZipFile.getEntryPos double loop queries
by Eirik Bjørsnøs 16 Apr '20

16 Apr '20

Hi, ZipEntry.getEntryPos currently has a double loop which retries search after a failed lookup by appending a '/' to the name/hash. This means that any miss needs to query the hash table twice. The following patch updates hashN to truncate any '/' at the end of an entry name. This ensures that the hash of META-INF and META-INF/ will always collide and the double query loop is no longer needed. I'm seeing ~35% time saving on misses and a slight improvement on hits. Removing the double loop also improves readability. diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java index 274e8788d1..fd6a4e276c 100644 --- a/src/java.base/share/classes/java/util/zip/ZipFile.java +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java @@ -1266,6 +1266,9 @@ public class ZipFile implements ZipConstants, Closeable { } private static final int hashN(byte[] a, int off, int len) { + if(a[off + len -1] == '/') { + len--; + } int h = 1; while (len-- > 0) { h = 31 * h + a[off++]; @@ -1493,48 +1496,31 @@ public class ZipFile implements ZipConstants, Closeable { int hsh = hashN(name, 0, name.length); int idx = table[(hsh & 0x7fffffff) % tablelen]; /* - * This while loop is an optimization where a double lookup - * for name and name+/ is being performed. The name char - * array has enough room at the end to try again with a - * slash appended if the first table lookup does not succeed. + * Search down the target hash chain for a entry whose + * 32 bit hash matches the hashed name. */ - while (true) { - /* - * Search down the target hash chain for a entry whose - * 32 bit hash matches the hashed name. - */ - while (idx != ZIP_ENDCHAIN) { - if (getEntryHash(idx) == hsh) { - // The CEN name must match the specfied one - int pos = getEntryPos(idx); - if (name.length == CENNAM(cen, pos)) { - boolean matched = true; - int nameoff = pos + CENHDR; - for (int i = 0; i < name.length; i++) { - if (name[i] != cen[nameoff++]) { - matched = false; - break; - } - } - if (matched) { - return pos; + while (idx != ZIP_ENDCHAIN) { + if (getEntryHash(idx) == hsh) { + // The CEN name must match the specfied one + int pos = getEntryPos(idx); + final int nlen = CENNAM(cen, pos); + if (name.length == nlen || (addSlash && name.length == nlen - 1 && cen[pos + CENHDR + nlen - 1] == '/')) { + boolean matched = true; + int nameoff = pos + CENHDR; + for (int i = 0; i < name.length; i++) { + if (name[i] != cen[nameoff++]) { + matched = false; + break; } - } + } + if (matched) { + return pos; + } } - idx = getEntryNext(idx); - } - /* If not addSlash, or slash is already there, we are done */ - if (!addSlash || name.length == 0 || name[name.length - 1] == '/') { - return -1; } - /* Add slash and try once more */ - name = Arrays.copyOf(name, name.length + 1); - name[name.length - 1] = '/'; - hsh = hash_append(hsh, (byte)'/'); - //idx = table[hsh % tablelen]; - idx = table[(hsh & 0x7fffffff) % tablelen]; - addSlash = false; + idx = getEntryNext(idx); } + return -1; } /**

2 3

RFR 8241749: Remove the Nashorn JavaScript Engine
by sundararajan.athijegannathan＠oracle.com 16 Apr '20

16 Apr '20

Please review. Nashorn script engine modules (jdk.scripting.nashorn, jdk.scripting.nashorn.shell) and jjs tool are removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8241749 JEP: https://openjdk.java.net/jeps/372 CSR: https://bugs.openjdk.java.net/browse/JDK-8241751 Webrev: http://cr.openjdk.java.net/~sundar/8241749/webrev.00/index.html Few tests that use nashorn are worked around by @ignore or deleting relevant nashorn test sections. Separate test bugs have been filed to handle these. https://bugs.openjdk.java.net/browse/JDK-8242860 https://bugs.openjdk.java.net/browse/JDK-8242859 https://bugs.openjdk.java.net/browse/JDK-8242858 https://bugs.openjdk.java.net/browse/JDK-8241982 https://bugs.openjdk.java.net/browse/JDK-8235594 Thanks, -Sundar

4 5

Need sponsor to fix Javadoc warnings
by Vipin Sharma 15 Apr '20

15 Apr '20

Hi, I have fixed a few warnings where the method parameter name is different in code and Javadoc, need a sponsor for this patch. Webrev is available at https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e Regards, Vipin

7 21