April 2021 - core-libs-dev

RFR: JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug
by Andy Herrick 01 May '21

01 May '21

JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug just disabling this test when vm.debug ------------- Commit messages: - JDK-8266129: tools/jpackage/windows/WinInstallerIconTest.java hangs with fastdebug Changes: https://git.openjdk.java.net/jdk/pull/3827/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3827&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266129 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3827.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3827/head:pull/3827 PR: https://git.openjdk.java.net/jdk/pull/3827

3 3

RFR: 8265356: need code example for getting canonical constructor of a Record
by Tagir F.Valeev 01 May '21

01 May '21

I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static <T extends Record>\nConstructor<T> getCanonicalConstructor(Class<T> cls)` is unnecessary. --- Aside from this PR, I've found a couple of things to clean up in `java.lang.Class`: 1. There's erroneous JavaDoc link in `getSimpleName()` JavaDoc (introduced by @jddarcy in #3038). It should be `#isArray()` instead of `isArray()`. 2. Methods Atomic::casAnnotationType and Atomic::casAnnotationData have unused type parameters `<T>`. 3. Probably too much but AnnotationData can be nicely converted to a record! Not sure, probably nobody wants to have `java.lang.Record` initialized too early or increasing the footprint of such a basic class in the metaspace, so I don't insist on this. private record AnnotationData( Map<Class<? extends Annotation>, Annotation> annotations, Map<Class<? extends Annotation>, Annotation> declaredAnnotations, // Value of classRedefinedCount when we created this AnnotationData instance int redefinedCount) { } Please tell me if it's ok to fix 1 and 2 along with this PR. ------------- Commit messages: - 8265356: need code example for getting canonical constructor of a Record Changes: https://git.openjdk.java.net/jdk/pull/3556/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3556&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265356 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3556.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3556/head:pull/3556 PR: https://git.openjdk.java.net/jdk/pull/3556

2 7

8252827: Caching Integer.toString just like Integer.valueOf
by Raffaello Giulietti 30 Apr '21

30 Apr '21

Hello, does the enhancement proposed in [1] make sense, both today and when wrappers will be migrated to primitive classes? If so, it should be rather simple to add it and I could prepare a PR. If not, the issue might perhaps be closed. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8252827

7 9

RFR: 8266155: Convert java.base to use Stream.toList()
by Ian Graves 30 Apr '21

30 Apr '21

8266155: Convert java.base to use Stream.toList() ------------- Commit messages: - Migrating java.base to use Stream.toList() Changes: https://git.openjdk.java.net/jdk/pull/3734/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3734&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266155 Stats: 18 lines in 8 files changed: 0 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3734.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3734/head:pull/3734 PR: https://git.openjdk.java.net/jdk/pull/3734

6 9

RFR: 8260560: convert jdeps and jdeprscan tools to use Stream.toList()
by Ian Graves 30 Apr '21

30 Apr '21

8260560: convert jdeps and jdeprscan tools to use Stream.toList() ------------- Commit messages: - Updating jdeps and jdeprscan to use Stream.toList() Changes: https://git.openjdk.java.net/jdk/pull/3705/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3705&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260560 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3705.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3705/head:pull/3705 PR: https://git.openjdk.java.net/jdk/pull/3705

4 4

RFR: 8266078: Reader.read(CharBuffer) advances Reader position for read-only Charbuffers
by Brian Burkhalter 29 Apr '21

29 Apr '21

Please consider this request to modify `Reader.read(CharBuffer)` to check whether the buffer is read-only before reading any characters from the character stream. This can happen now if the buffer is read-only. Character are first read thereby advancing the stream before an attempt is made to put them in the `CharBuffer` thus incorrectly advancing the stream position. ------------- Commit messages: - 8266078: Reader.read(CharBuffer) advances Reader position for read-only Charbuffers Changes: https://git.openjdk.java.net/jdk/pull/3725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266078 Stats: 70 lines in 2 files changed: 70 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3725/head:pull/3725 PR: https://git.openjdk.java.net/jdk/pull/3725

4 8

RFR: 8266014: Regression brought by optimization done with JDK-4926314
by Brian Burkhalter 29 Apr '21

29 Apr '21

Please consider this request to correct a minor problem with the optimization added for JDK-4926314. The change is to attempt to read the number of elements remaining in the target buffer unless that number is non-positive in which case read zero. The test addition fails without and passes with the implementation change. ------------- Commit messages: - 8266014: Regression brought by optimization done with JDK-4926314 Changes: https://git.openjdk.java.net/jdk/pull/3708/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3708&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266014 Stats: 20 lines in 2 files changed: 16 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3708.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3708/head:pull/3708 PR: https://git.openjdk.java.net/jdk/pull/3708

4 5

RFR: 8265918: java/io/Console/CharsetTest.java failed with "expect: spawn id exp6 not open"
by Naoto Sato 29 Apr '21

29 Apr '21

This new regression test was introduced with the Console::charset(), but it fails on ubuntu platforms assuming its locales/encoding incorrectly. To not make false-alarm/noise on test runs, this fix minimizes the tests not depending on the underlying OS's environment variables. ------------- Commit messages: - 8265918: java/io/Console/CharsetTest.java failed with "expect: spawn id exp6 not open" Changes: https://git.openjdk.java.net/jdk/pull/3768/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3768&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265918 Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3768/head:pull/3768 PR: https://git.openjdk.java.net/jdk/pull/3768

3 3

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5]
by Yi Yang 29 Apr '21

29 Apr '21

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: AssertionError when expected exception was not thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/bbdf4b9e..1a96be7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03-04 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615

2 2

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4]
by Yi Yang 29 Apr '21

29 Apr '21

> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove extra newline ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/db8b6ef4..bbdf4b9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615

2 2