March 2021 - core-libs-dev

Comment on CSR 8251991: Hex formatting and parsing utility
by Raffaello Giulietti 15 Mar '21

15 Mar '21

Hello, it appears that all of the following API methods in [1] can be declared *static*, which makes them more useful in contexts where there's no instance of HexFormat available or none is desired. As 17 has not yet entered any formal phase, the change should be harmless. public boolean isHexDigit(int); public int fromHexDigit(int); public int fromHexDigits(java.lang.CharSequence); public int fromHexDigits(java.lang.CharSequence, int, int); public long fromHexDigitsToLong(java.lang.CharSequence); public long fromHexDigitsToLong(java.lang.CharSequence, int, int); Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8251991

2 2

RFR: 8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException
by Craig Andrews 15 Mar '21

15 Mar '21

_NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151) `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`. According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved. Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String)) > Returns: > a URL for the resource, or null if the resource could not be found, or if the loader is closed. And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String)) > Returns: > URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager. Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned. Here's a stack trace: java.lang.IllegalArgumentException: name at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600) at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291) at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655) at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652) Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603) URL findResource(final String name, boolean check) { URL url; try { url = new URL(base, ParseUtil.encodePath(name, false)); } catch (MalformedURLException e) { throw new IllegalArgumentException("name"); } Instead of throwing `IllegalArgumentException`, that line should simply return `null`. A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639) URL findResource(final String name, boolean check) { URL url; try { url = new URL(base, ParseUtil.encodePath(name, false)); } catch (MalformedURLException e) { throw new IllegalArgumentException("name"); } Instead of throwing `IllegalArgumentException`, that line should simply return `null`. ------------- Commit messages: - 8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException Changes: https://git.openjdk.java.net/jdk/pull/2662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262277 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2662/head:pull/2662 PR: https://git.openjdk.java.net/jdk/pull/2662

6 25

RFR: 8263556: remove `@modules java.base` from tests
by Igor Ignatyev 15 Mar '21

15 Mar '21

Hi all, could you please review this trivial cleanup? from JBS: > jtreg `@modules X` directive does two things: > - exclude a test from execution if JDK under test doesn't have module X > - if JDK under test has module X, make sure it's resolved > > both these things have no sense for `java.base` module as it's always available and is always resolved. Thanks, -- Igor ------------- Commit messages: - update copyright year - 8263556: remove `@modules java.base` from tests Changes: https://git.openjdk.java.net/jdk/pull/2990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263556 Stats: 21 lines in 13 files changed: 0 ins; 13 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2990/head:pull/2990 PR: https://git.openjdk.java.net/jdk/pull/2990

4 5

java.io.Serial vs java.io.Serializable javadoc
by Zheka Kozlov 15 Mar '21

15 Mar '21

Hi! The javadoc of java.io.Serial [1] says that serialVersionUID is private. But the javadoc of Serializable [2] says it can have any access modifier. Who is right here? When I write the following code, should there be a warning or not? import java.io.Serial;import java.io.Serializable; public class SerExample implements Serializable { @Serial // warning or not? public static final long serialVersionUID = 2L;} This question originated in this [3] discussion in the IDEA bugtracker. With best regards, Zheka. [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serial… [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serial… [3] https://youtrack.jetbrains.com/issue/IDEA-230392

2 1

RFR: 8263552: Use String.valueOf() for char-to-String conversion in ObjectStreamClass
by Сергей Цыпанов 15 Mar '21

15 Mar '21

This is a very simple and trivial improvement about getting rid of pointless char wrapping into array ------------- Commit messages: - Fix other occurences - Use String.valueOf() for char-to-String conversion in ObjectStreamClass Changes: https://git.openjdk.java.net/jdk/pull/2660/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2660&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263552 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2660.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2660/head:pull/2660 PR: https://git.openjdk.java.net/jdk/pull/2660

8 19

RFR: 8263508: Remove dead code in MethodHandleImpl
by Claes Redestad 15 Mar '21

15 Mar '21

Remove unused methods. ------------- Commit messages: - Revert assertSame removal (used from InvokerByteCodeGenerator) - Remove dead code in MethodHandleImpl Changes: https://git.openjdk.java.net/jdk/pull/2969/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2969&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263508 Stats: 103 lines in 1 file changed: 0 ins; 103 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2969/head:pull/2969 PR: https://git.openjdk.java.net/jdk/pull/2969

3 4

RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
by Jim Laskey 15 Mar '21

15 Mar '21

This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . ------------- Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - Merge branch 'master' into 8248862 - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators - Merge branch 'master' into 8248862 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/9efbb463...7469ca58 Changes: https://git.openjdk.java.net/jdk/pull/1273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 14875 lines in 31 files changed: 11094 ins; 3704 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273 PR: https://git.openjdk.java.net/jdk/pull/1273

9 24

RFR: 8263549: 8263412 can cause jtreg testlibrary split
by Igor Ignatyev 13 Mar '21

13 Mar '21

Hi all, could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used). from JBS: > after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. testing: - [x] `grep ' ClassFileInstaller[^.]` - [ ] tier1-3 Thanks, -- Igor ------------- Commit messages: - fixup - update copyright year - rm test/lib/ClassFileInstaller.java - 's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g' Changes: https://git.openjdk.java.net/jdk/pull/2985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263549 Stats: 1736 lines in 867 files changed: 0 ins; 67 del; 1669 mod Patch: https://git.openjdk.java.net/jdk/pull/2985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985 PR: https://git.openjdk.java.net/jdk/pull/2985

3 9

RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package
by Igor Ignatyev 12 Mar '21

12 Mar '21

Hi all, could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls `jdk.test.lib.helpers. ClassFileInstaller::main`. from JBS: > ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. > > to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl. > > the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8263412). testing: - [x] `:jdk_core` against `{macos,windows,linux}-x64` - [x] `:jdk_svc` against `{macos,windows,linux}-x64` - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64` Thanks, -- Igor ------------- Commit messages: - make ClassFileInstaller.Manifest::from* public - updated copyright years - import j.t.l.helpers.ClassFileInstaller - added jdk/test/lib/helpers/ClassFileInstaller Changes: https://git.openjdk.java.net/jdk/pull/2932/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2932&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263412 Stats: 473 lines in 114 files changed: 145 ins; 229 del; 99 mod Patch: https://git.openjdk.java.net/jdk/pull/2932.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2932/head:pull/2932 PR: https://git.openjdk.java.net/jdk/pull/2932

4 5

RFR: 8261031: Move some ClassLoader name checking to native/VM
by Claes Redestad 12 Mar '21

12 Mar '21

This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. ------------- Commit messages: - Copyrights - Move class name checking for findBootstrapClass/findLoadedClass into native/VM Changes: https://git.openjdk.java.net/jdk/pull/2378/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261031 Stats: 20 lines in 3 files changed: 11 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2378/head:pull/2378 PR: https://git.openjdk.java.net/jdk/pull/2378

3 12