November 2021 - core-libs-dev

Adding an @Immutable annotation to Java
by Alberto Otero Rodríguez 30 Nov '21

30 Nov '21

Hi, I was thinking that it could be interesting adding an @Immutable annotation to Java. It would be a marker annotation for the compiler (similar to @FunctionalInterface) in order to throw an error if the annotated class/record has a component that is not @Immutable. This means that all existing immutable objects (like the primitive-wrapping objects and String) should be annotated with @Immutable and the programmer could, for example, annotate a new record object with @Immutable only if all its fields are annotated with @Immutable. What do you think? Regards, Alberto Otero Rodríguez.

9 11

8276766: Discuss options for deterministic jar/jmod timestamps across timezones
by Andrew Leonard 30 Nov '21

30 Nov '21

*Problem:* PR https://github.com/openjdk/jdk/pull/6481 addresses the main problems with deterministic timestamping of Zip entries, with the introduction of a new --date <ISO-8601-date-time> option for jar & jmod. However, the ZipEntry timestamp is constructed from a combination of an MS-DOS timestamp and a FileTime(seconds since epoch). MS-DOS timestamp is used between 1980->2106, FileTime is used outside that range. The problem arises in deterministically setting the ZipEntry times within JVMs with different default system time-zones. This occurs because ZipEntry.setTime(long millisSinceEpoch) or setTimeLocal(LocalDateTime) are unaware of time-zones. So when setTime has to calculate the msdostime from millisSinceEpoch, it has to query the system time-zone to work out what the "date-time" is. Similarly, for setTimeLocal(LocalDateTime), if the LocalDateTime is outside 1980-2106 range, then it has to create a FileTime, hence again it has to use the system time-zone to work out how many seconds since epoch the LocalDateTime is. *Solutions proposed so far:* 1. Take the --date <ISO-8601-datetime> value and create a LocalDateTime eg.1982-12-09T14:02:06, and call ZipEntry.setTimeLocal(with LocalDateTime"1982-12-09T14:02:06"). For the same input and across time-zones the ZipEntry is deterministic when within the valid MS-DOS time range (1980->2106), because no extended FileTime is created. Pros: - No API changes, uses existing ZipEntry.setTimeLoca(LocalDateTime) Cons: - Is only determinstic between years 1980->2106, outside this range a FileTime is generated using the system time-zone. 2. Add new "Zoned" set/get methods to ZipEntry, so that ZipEntry does not have to defer to the system time-zone. By adding set/getTimeZoned(ZonedDateTime), set/getLastModifiedTimeZoned(FileTime, ZoneId) methods to ZipEntry the ZipEntry MS-DOS time and extended FileTime can be set precisely and deterministically to the user supplied date-time. Pros: - ZipEntry is always deterministically created for the same input --date <ISO-8601-datetime>, across different JVM time-zones, for all time ranges. Cons: - An API addition is required to ZipEntry to add new "Zoned" set/get time methods. Thoughts, comments, or alternatives most welcome please? Thanks Andrew

2 3

RFR: 8277957: Add test group for IPv6 exclusive testing
by Ivan Šipka 29 Nov '21

29 Nov '21

Adding test group for IPv6 exclusive testing. ------------- Commit messages: - 8277957: add IPv6 test group Changes: https://git.openjdk.java.net/jdk/pull/6600/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6600&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277957 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6600.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6600/head:pull/6600 PR: https://git.openjdk.java.net/jdk/pull/6600

1 0

8276766: Discuss options for deterministic jar/jmod timestamps across timezones
by Andrew Leonard 29 Nov '21

29 Nov '21

Given an API-change is not realistic at this point in jdk-18, would it make more sense to implement solution (1), and consider (2) for jdk-19+.. ?

1 0

String.indexOf(single-char-String)
by Michael Bien 27 Nov '21

27 Nov '21

Hello, I kept forgetting which variants of the String methods perform better with single-char-Strings and which with char (IDEs had the tendency to suggest the wrong variant since it changed between JDK releases). So i wrote JMH benchmarks and noticed that the last method with a performance difference seems to be String.indexOf() - all other variants performed equally (unless I overlooked some). this might be fairly easy to fix: https://github.com/openjdk/jdk/pull/6509 (side effect: contains("c") is also faster) I haven't looked into the intrinsified code of StringLatin1 and StringUTF16 to check if it could be fixed there (mostly because i actually don't know how the JVM assembles those intrinsics). It might be possible to improve this for short Strings in general, not just for chars, dependent on why the intrinsified version is actually slower for single-char-Strings. I opted for the trivial fix in java code. best regards, michael

2 5

RFR: 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs
by Stuart Monteith 26 Nov '21

26 Nov '21

Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread to finish before restarting trial method. ------------- Commit messages: - 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs Changes: https://git.openjdk.java.net/jdk/pull/6560/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6560&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277659 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6560.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6560/head:pull/6560 PR: https://git.openjdk.java.net/jdk/pull/6560

4 6

RFR: 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories
by Mandy Chung 26 Nov '21

26 Nov '21

jdeps intends to report an error if there are multiple versions of the same class being parsed. module-info.class should be excluded from such detection. This patch also fixes a data race in `VersionHelper::set` and also unwraps the `ExecutionException` when FutureTask of parsing the classes throws an exception to report `MultiReleaseException` properly. ------------- Commit messages: - add comment to the test - JDK-8277165: jdeps cannot handle 2 jars that put module-info.class in a different versioned directory Changes: https://git.openjdk.java.net/jdk/pull/6530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277165 Stats: 301 lines in 11 files changed: 288 ins; 6 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6530/head:pull/6530 PR: https://git.openjdk.java.net/jdk/pull/6530

5 9

RFR: 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs
by Stuart Monteith 25 Nov '21

25 Nov '21

Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread to finish before restarting trial method. ------------- Commit messages: - 8277659: [TESTBUG] ThreadOnSpinWaitProducerConsumer hangs Changes: https://git.openjdk.java.net/jdk/pull/6559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277659 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6559/head:pull/6559 PR: https://git.openjdk.java.net/jdk/pull/6559

1 1

RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time
by Jaikiran Pai 25 Nov '21

25 Nov '21

The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117. The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor. This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here: 1. When creating a jar (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases. If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry. ------------- Commit messages: - 8258117: jar tool sets the time stamp of module-info.class entries to the current time Changes: https://git.openjdk.java.net/jdk/pull/5486/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258117 Stats: 317 lines in 2 files changed: 298 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/5486.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486 PR: https://git.openjdk.java.net/jdk/pull/5486

7 29

RFR: 8277806: 4 tools/jar failures per platform after JDK-8272728
by Lance Andersen 24 Nov '21

24 Nov '21

HI all, Attached is a patch for 4 failing MR tests due the issue that was resolved via JDK-8272728 Best Lance ------------- Commit messages: - Fix for JDK-8272728 Changes: https://git.openjdk.java.net/jdk/pull/6546/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6546&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277806 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6546.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6546/head:pull/6546 PR: https://git.openjdk.java.net/jdk/pull/6546

3 3