January 2021 - core-libs-dev

Integrated: 8226810: Failed to launch JVM because of NullPointerException occured on System.props
by Evan Whelan 12 Jan '21

12 Jan '21

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan(a)openjdk.org> wrote: > Hi, > > Please review this small change which enables the GB18030 charset to be built into java.base > > Thanks This pull request has now been integrated. Changeset: 5f7ccce0 Author: Evan Whelan <ewhelan(a)openjdk.org> Committer: Alan Bateman <alanb(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/5f7ccce0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8226810: Failed to launch JVM because of NullPointerException occured on System.props Reviewed-by: alanb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2053

1 0

Re: RFR: 8226810: Failed to launch JVM because of NullPointerException occured on System.props
by Naoto Sato 12 Jan '21

12 Jan '21

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan(a)openjdk.org> wrote: > Hi, > > Please review this small change which enables the GB18030 charset to be built into java.base > > Thanks Looks fine. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2053

1 0

[jdk16] RFR: 8259634: MemorySegment::asByteBuffer does not respect spatial bounds
by Maurizio Cimadamore 12 Jan '21

12 Jan '21

The byte buffers created from heap segments do not honor the javadoc - which says that the resulting buffer size should be equal to MemorySegment::byteSize, and that the buffer position should be zero. The issue is that the NIO routine we have added to create heap buffers is using the wrong constructor, which doesn't do what we need. The fix is to simply use the proper, more complete constructor. I've also re-enabled an unrelated test which was missing the @Test annotation. ------------- Commit messages: - Fix loic to turn segments into buffers Changes: https://git.openjdk.java.net/jdk16/pull/109/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=109&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259634 Stats: 30 lines in 2 files changed: 28 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk16/pull/109

3 3

[jdk16] RFR: 8259298: broken link in Stream::toList spec
by Stuart Marks 12 Jan '21

12 Jan '21

Just fixing a broken link. ------------- Commit messages: - 8259298: broken link in Stream::toList spec Changes: https://git.openjdk.java.net/jdk16/pull/106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259298 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/106.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/106/head:pull/106 PR: https://git.openjdk.java.net/jdk16/pull/106

5 5

Re: RFR: 8226810: Failed to launch JVM because of NullPointerException occured on System.props
by Alan Bateman 12 Jan '21

12 Jan '21

On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan <ewhelan(a)openjdk.org> wrote: > Hi, > > Please review this small change which enables the GB18030 charset to be built into java.base > > Thanks Including GB18030 in java.base rather than jdk.charsets on Windows is fine. It does increase the size of java.base but that is less of a concern now than it used to be. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2053

1 0

Is SharedSecrets thread-safe?
by some-java-user-99206970363698485155＠vodafonemail.de 12 Jan '21

12 Jan '21

Hello, the class `jdk.internal.access.SharedSecrets` provides getter methods which all look similar to this: ``` if (static_field == null) { initialize(); } return static_field; ``` However, neither the static fields are `volatile` nor are the getter methods synchronized. So if my understanding of the Java Memory Model is correct, the compiler is free to reorder the two static field reads. So it is in theory possible that the first read yields a non-`null` value, but the second read yields a `null` value which leads to incorrect behavior (for further reading [1]). It is probably rather unlikely that this actually happens because `SharedSecrets` is in most cases accessed from static initializers (which are only run once) and because not many classes access the same `SharedSecrets` fields. Is this analysis correct or did I forget to consider parts of the Memory Model logic, or is there some JVM magic I am missing? Kind regards [1] https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign…

8 16

RFR: JDK-8223322: Improve concurrency in jpackage instances
by Andy Herrick 12 Jan '21

12 Jan '21

Remove all non final static variables in jpackage java code (using InheritableThreadLocal for Logger and Argument instances) and remove sychronization in JPackageToolProvider. ------------- Commit messages: - JDK-8223322: Improve concurrency in jpackage instances - JDK-8223322: Improve concurrency in jpackage instances Changes: https://git.openjdk.java.net/jdk/pull/1829/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1829&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223322 Stats: 214 lines in 8 files changed: 134 ins; 52 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1829/head:pull/1829 PR: https://git.openjdk.java.net/jdk/pull/1829

3 11

[PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
by yano-masanori＠fujitsu.com 12 Jan '21

12 Jan '21

Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -----Original Message----- > From: Yano, Masanori > Sent: Wednesday, November 4, 2020 6:03 PM > To: 'core-libs-dev(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> > Subject: 8250678: ModuleDescriptor.Version parsing treats empty segments > inconsistently > > Hello. > > I would like to contribute for JDK-8250678. > > The 'parse' method of ModuleDescriptor.Version class behaves incorrectly when the > input string contains consecutive delimiters. > > The 'parse' method treats strings as three sections, but the parsing method differs > between the method for the version sections and the ones for others. > In version sections, the 'parse' method takes a single character in a loop and > determines whether it is a delimiter. In pre and build sections, the parse method takes > two characters in a loop and determines whether the second character is the delimiter. > Therefore, if the string contains a sequence of delimiters in pre or build section, the > 'parse' method treats character at the odd-numbered position as a token and the one > at even-numbered as a delimiter > > A string containing consecutive delimiters is an incorrect version string, but this > behavior does not follow the API specification. > https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/l… > module/ModuleDescriptor.Version.html > > Therefore, I propose to fix the parsing method of the pre section and the build section > in the same way as the version. > > Please sponsor the following change. > > diff -r bdc20ee1a68d > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > Fri Sep 04 23:51:26 2020 -0400 > +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > Wed Oct 28 17:06:47 2020 +0900 > @@ -1053,13 +1053,6 @@ > > while (i < n) { > c = v.charAt(i); > - if (c >= '0' && c <= '9') > - i = takeNumber(v, i, pre); > - else > - i = takeString(v, i, pre); > - if (i >= n) > - break; > - c = v.charAt(i); > if (c == '.' || c == '-') { > i++; > continue; > @@ -1068,6 +1061,10 @@ > i++; > break; > } > + if (c >= '0' && c <= '9') > + i = takeNumber(v, i, pre); > + else > + i = takeString(v, i, pre); > } > > if (c == '+' && i >= n) > @@ -1075,17 +1072,14 @@ > > while (i < n) { > c = v.charAt(i); > + if (c == '.' || c == '-' || c == '+') { > + i++; > + continue; > + } > if (c >= '0' && c <= '9') > i = takeNumber(v, i, build); > else > i = takeString(v, i, build); > - if (i >= n) > - break; > - c = v.charAt(i); > - if (c == '.' || c == '-' || c == '+') { > - i++; > - continue; > - } > } > > this.version = v; > diff -r bdc20ee1a68d test/jdk/java/lang/module/VersionTest.java > --- a/test/jdk/java/lang/module/VersionTest.java Fri Sep 04 23:51:26 2020 > -0400 > +++ b/test/jdk/java/lang/module/VersionTest.java Wed Oct 28 17:06:47 > 2020 +0900 > @@ -148,6 +148,8 @@ > { "1", "1.0.0" }, > { "1.0", "1.0.0" }, > { "1.0-beta", "1.0.0-beta" }, > + { "1.0-1.1", "1.0-1..1" }, > + { "1.0-1+1", "1.0-1.+1" }, > > }; > } > > Regards, > Masanori Yano

1 1

RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in si…
by Hai-May Chao 12 Jan '21

12 Jan '21

The jarsigner tool currently provides warning associated with the signer’s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer’s cert chain to warn if CA certs use weak algorithms. ------------- Commit messages: - 8259401: Add checking to jarsigner to warn weak algorithms used in signer’s cert chain Changes: https://git.openjdk.java.net/jdk/pull/2042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259401 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042

1 0

RFR: Merge jdk16
by Jesper Wilhelmsson 12 Jan '21

12 Jan '21

Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl - 8259043: More Zero architectures need linkage with libatomic - 8259429: Update reference to README.md - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2040/files Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040

1 2