May 2021 - core-libs-dev

RFR: 8267587: Update java.util to use enhanced switch
by Tagir F.Valeev 31 May '21

31 May '21

Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement? ------------- Commit messages: - 8267587: Update java.util to use enhanced switch Changes: https://git.openjdk.java.net/jdk/pull/4161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267587 Stats: 887 lines in 17 files changed: 113 ins; 339 del; 435 mod Patch: https://git.openjdk.java.net/jdk/pull/4161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161 PR: https://git.openjdk.java.net/jdk/pull/4161

6 24

Proposal for new interface: TimeSource
by Stephen Colebourne 28 May '21

28 May '21

This is a proposal to add a new interface to java.time.* public interface TimeSource { public static TimeSource system() { ... } public abstract Instant instant(); public default long millis() { return instant().toEpochMilli(); } public default Clock withZone(ZoneId zoneId) { return Clock.of(this, zoneId); } } The existing `Clock` abstract class would be altered to implement the interface. A new static method `Clock.of(TimeSource, ZoneId)` would be added. No changes are needed to any other part of the API. (Could add `Instant.now(TimeSource)`, but it isn't entirely necessary) Callers would pass around and use `TimeSource` directly, for example by dependency injection. Why add this interface? I've seen various indications that there is a desire for an interface representing a supplier of `Instant`. Specifically this desire is driven by the "unnecessary" time zone that `java.time.Clock` contains. Put simply, if the only thing you want is an `Instant`, then `Clock` isn't the right API because it forces you to think about time zones. A key thing that this interface allows is the separation of the OS Clock from the time-zone (which should generally be linked to user localization). A good architecture would pass `TimeSource` around the system and combine it with a time-zone held in a `UserContext` to get a `Clock`. The current design of java.time.* does not enable that because the `TimeSource` concept does not exist. Developers either have to write their own interface, or use `Clock` and ignore the time zone. A `Supplier<Instant>` obviously performs similar functionality, but it lacks discoverability and understandability. Plus, injecting generified interfaces tends to be painful. Downsides? None really, other than a new type in the JDK that probably should have been in Java 8. See this ThreeTen-Extra discussion - https://github.com/ThreeTen/threeten-extra/issues/150 Joda-Time has a `MillisProvider` that is similar: - https://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeUtils.MillisPr… Time4J has a `TimeSource`: - https://github.com/MenoData/Time4J/blob/master/base/src/main/java/net/time4… Spring has a `DateTimeContext` that separates the user localization as per the `UserContext` described above: - https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spring… There is a similar concept `TimeSource` in `sun.net.httpserver` There may be a case to name the interface `InstantSource`, however `TimeSource` is a fairly widely understood name for this concept. There is the potential to extend the interface with something similar to Kotlin's `TimeMark` that would allow access to the monotonic clock, suitable for measurement of durations without any leap second effects: - https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.time/-time-mark/ Feedback? Stephen

5 6

RFR: 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException
by Aleksei Efimov 28 May '21

28 May '21

Hi, `com/sun/jndi/dns/ConfigTests/Timeout.java ` was seen failing intermittently with "Address already in use" `BindException`. The reason of this failure is that `disconnect` call in JNDI `DnsClient` fails to rebind the datagram socket to the original port during `disconnect` call (the failure is in `DatagramChannel::repairSocket`). Since Datagram socket is not reused and closed after the failure `finally` block with the `disconnect` call can be removed. The fix was tested with all available JNDI/DNS tests, and no failures related to the change were observed. ------------- Commit messages: - 8265309: com/sun/jndi/dns/ConfigTests/Timeout.java fails with "Address already in use" BindException Changes: https://git.openjdk.java.net/jdk/pull/4227/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4227&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265309 Stats: 30 lines in 1 file changed: 0 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4227.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4227/head:pull/4227 PR: https://git.openjdk.java.net/jdk/pull/4227

2 5

RFR: 8265418: Clean-up redundant null-checks of Class.getPackageName()
by Сергей Цыпанов 28 May '21

28 May '21

As discussed in https://github.com/openjdk/jdk/pull/3464 we can clean-up null-checks remaining after [8142968](https://bugs.openjdk.java.net/browse/JDK-8142968) as Class.getPackageName() never returns null. ------------- Commit messages: - 8265418: Clean-up redundant null-checks of Class.getPackageName() Changes: https://git.openjdk.java.net/jdk/pull/3571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3571&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265418 Stats: 19 lines in 7 files changed: 1 ins; 8 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3571/head:pull/3571 PR: https://git.openjdk.java.net/jdk/pull/3571

5 22

RFR: JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit)
by Tagir F.Valeev 28 May '21

28 May '21

With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`, `toArray()` and `count()` may benefit from this. E. g., `LongStream.range(0, 10_000_000_000L).skip(1).count()` returns result instantly with this patch. Some microbenchmarks added that confirm the reduced memory allocation in `toList()` and `toArray()` cases. Before patch: ref.SliceToList.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40235,534 ± 0,984 B/op ref.SliceToList.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 106431,101 ± 0,198 B/op ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 106544,977 ± 1,983 B/op value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40121,878 ± 0,247 B/op value.SliceToArray.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 106317,693 ± 1,083 B/op value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 106430,954 ± 0,136 B/op After patch: ref.SliceToList.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40235,648 ± 1,354 B/op ref.SliceToList.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 40355,784 ± 1,288 B/op ref.SliceToList.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 40476,032 ± 2,855 B/op value.SliceToArray.seq_baseline:·gc.alloc.rate.norm 10000 thrpt 10 40121,830 ± 0,308 B/op value.SliceToArray.seq_limit:·gc.alloc.rate.norm 10000 thrpt 10 40242,554 ± 0,443 B/op value.SliceToArray.seq_skipLimit:·gc.alloc.rate.norm 10000 thrpt 10 40363,674 ± 1,576 B/op Time improvements are less exciting. It's likely that inlining and vectorizing dominate in these tests over array allocations and unnecessary copying. Still, I notice a significant improvement in SliceToArray.seq_limit case (2x) and mild improvement (+12..16%) in other slice tests. No significant change in parallel execution time, though its performance is much less stable and I didn't run enough tests. Before patch: Benchmark (size) Mode Cnt Score Error Units ref.SliceToList.par_baseline 10000 thrpt 30 14876,723 ± 99,770 ops/s ref.SliceToList.par_limit 10000 thrpt 30 14856,841 ± 215,089 ops/s ref.SliceToList.par_skipLimit 10000 thrpt 30 9555,818 ± 991,335 ops/s ref.SliceToList.seq_baseline 10000 thrpt 30 23732,290 ± 444,162 ops/s ref.SliceToList.seq_limit 10000 thrpt 30 14894,040 ± 176,496 ops/s ref.SliceToList.seq_skipLimit 10000 thrpt 30 10646,929 ± 36,469 ops/s value.SliceToArray.par_baseline 10000 thrpt 30 25093,141 ± 376,402 ops/s value.SliceToArray.par_limit 10000 thrpt 30 24798,889 ± 760,762 ops/s value.SliceToArray.par_skipLimit 10000 thrpt 30 16456,310 ± 926,882 ops/s value.SliceToArray.seq_baseline 10000 thrpt 30 69669,787 ± 494,562 ops/s value.SliceToArray.seq_limit 10000 thrpt 30 21097,081 ± 117,338 ops/s value.SliceToArray.seq_skipLimit 10000 thrpt 30 15522,871 ± 112,557 ops/s After patch: Benchmark (size) Mode Cnt Score Error Units ref.SliceToList.par_baseline 10000 thrpt 30 14793,373 ± 64,905 ops/s ref.SliceToList.par_limit 10000 thrpt 30 13301,024 ± 1300,431 ops/s ref.SliceToList.par_skipLimit 10000 thrpt 30 11131,698 ± 1769,932 ops/s ref.SliceToList.seq_baseline 10000 thrpt 30 24101,048 ± 263,528 ops/s ref.SliceToList.seq_limit 10000 thrpt 30 16872,168 ± 76,696 ops/s ref.SliceToList.seq_skipLimit 10000 thrpt 30 11953,253 ± 105,231 ops/s value.SliceToArray.par_baseline 10000 thrpt 30 25442,442 ± 455,554 ops/s value.SliceToArray.par_limit 10000 thrpt 30 23111,730 ± 2246,086 ops/s value.SliceToArray.par_skipLimit 10000 thrpt 30 17980,750 ± 2329,077 ops/s value.SliceToArray.seq_baseline 10000 thrpt 30 66512,898 ± 1001,042 ops/s value.SliceToArray.seq_limit 10000 thrpt 30 41792,549 ± 1085,547 ops/s value.SliceToArray.seq_skipLimit 10000 thrpt 30 18007,613 ± 141,716 ops/s I also modernized SliceOps a little bit, using switch expression (with no explicit default!) and diamonds on anonymous classes. ------------- Commit messages: - Convert line endings - JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit) Changes: https://git.openjdk.java.net/jdk/pull/3427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265029 Stats: 377 lines in 9 files changed: 312 ins; 7 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/3427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3427/head:pull/3427 PR: https://git.openjdk.java.net/jdk/pull/3427

4 25

RFR: 8267529: StringJoiner can create a String that breaks String::equals
by Claes Redestad 27 May '21

27 May '21

This patch fixes a regression caused by https://bugs.openjdk.java.net/browse/JDK-8265237 where the result of String.join always get a UTF-16 coder if the delimiter is UTF-16, even when no delimiter is emitted. ------------- Commit messages: - Fix copyright, @bug - 8267529: StringJoiner can create a String that breaks String::equals Changes: https://git.openjdk.java.net/jdk/pull/4228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4228&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267529 Stats: 18 lines in 2 files changed: 14 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4228/head:pull/4228 PR: https://git.openjdk.java.net/jdk/pull/4228

2 4

Integrated: 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
by Daniel D.Daugherty 27 May '21

27 May '21

A trivial fix to ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java. ------------- Commit messages: - 8267886: ProblemList javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Changes: https://git.openjdk.java.net/jdk/pull/4231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267886 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4231/head:pull/4231 PR: https://git.openjdk.java.net/jdk/pull/4231

2 3

RFR: 8267123: Remove RMI Activation
by Stuart Marks 27 May '21

27 May '21

This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). This is a fairly straightforward removal of this component. - Activation implementation classes removed - Activation tests removed - adjustments to various comments to remove references to Activation - adjustments to some code to remove special-case support for Activation from core RMI - adjustments to several tests to remove testing and support for, and mentions of Activation - remove `rmid` tool (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) ------------- Commit messages: - Merge branch 'master' into JDK-8267123-Remove-RMI-Activation - Merge branch 'master' into remove-rmi-activation - Clean up some old comments. - Small fixups. - First cut at removal of RMI Activation. Changes: https://git.openjdk.java.net/jdk/pull/4194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267123 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4194/head:pull/4194 PR: https://git.openjdk.java.net/jdk/pull/4194

4 6

RFR: 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar
by Naoto Sato 27 May '21

27 May '21

Please review the fix. The issue was informed yesterday by @amaembo that it offends some code analysis tools. Although the fix is to change the condition error, it turned out that `JapaneseImperialCalendar.roll()` did not work for `WEEK_OF_MONTH` and `DAY_OF_MONTH`. There was an inherent issue where `GregorianCalendar` does not follow the `roll()` spec, i.e., "The MONTH must not change when the WEEK_OF_MONTH is rolled." during the Julian/Gregorian transition. JDK-6191841 seems to have tried to fix it but it was closed as `Future Project`... So I simply fixed the `roll()` issue in `JapaneseImperialCalendar` to follow the spec here, which seems to be the intent of the original author. ------------- Commit messages: - 8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar Changes: https://git.openjdk.java.net/jdk/pull/4191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8187649 Stats: 46 lines in 3 files changed: 36 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4191/head:pull/4191 PR: https://git.openjdk.java.net/jdk/pull/4191

3 3

RFR: 8240347: remove undocumented options from jlink --help message
by Athijegannathan Sundararajan 27 May '21

27 May '21

fixed constructor argument passing issue. ------------- Commit messages: - 8240347: remove undocumented options from jlink --help message Changes: https://git.openjdk.java.net/jdk/pull/4221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240347 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4221/head:pull/4221 PR: https://git.openjdk.java.net/jdk/pull/4221

3 3