Re: RFR: 8283683: Make ThreadLocalRandom a final class

2022-03-25 Thread Stuart Marks
On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` > class as `final`? Related JBS issue > https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too

Integrated: JDK-8283668: Update IllegalFormatException to use sealed classes

2022-03-25 Thread Joe Darcy
On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time > IllegalFormatException. > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8283669 This pull request has now been integrated. Changeset:

Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes

2022-03-25 Thread Joe Darcy
On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time > IllegalFormatException. > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8283669 > _Mailing list message from [Alan

Re: RFR: 8282819: Deprecate Locale class constructors [v3]

2022-03-25 Thread Naoto Sato
> Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `ill-formed` Locale objects, which is discouraged. We

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 17:27:32 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change >> to add 2nd parameter to

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from

Integrated: 8283681: Improve ZonedDateTime offset handling

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy

Re: RFR: 8282819: Deprecate Locale class constructors [v2]

2022-03-25 Thread Naoto Sato
On Fri, 25 Mar 2022 01:56:33 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java >> line 375: >> >>> 373: (locale.getLanguage().isEmpty() ? "und" : >>> locale.getLanguage()) + >>> 374:

Re: RFR: 8282819: Deprecate Locale class constructors [v2]

2022-03-25 Thread Naoto Sato
> Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create `ill-formed` Locale objects, which is discouraged. We

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Roger Riggs
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from

Re: [External] : Re: jpackage Windows support for 4 digits version

2022-03-25 Thread Alexey Semenyuk
Sverre, exe installers generated by jpackage are just wrappers for msi installers. Moving workaround you have in Gradle into jpackage will not solve the problem, but will hide it. This doesn't look appealing. We need a better solution. I created

Integrated: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char

2022-03-25 Thread Joe Wang
On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between > the parser and serializer. The parser rejected control characters while the > serializer converted them to NCRs. The fix is for the later to be aligned > with

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Naoto Sato
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from

Integrated: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar

2022-03-25 Thread Brent Christian
On Tue, 22 Mar 2022 17:59:15 GMT, Brent Christian wrote: > Please review this change to the java/util/prefs/AddNodeChangeListener.jar > test. > > Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh > Preferences on each test run, MacOS does not seem to honor this, and

Re: RFR: 8282819: Deprecate Locale class constructors

2022-03-25 Thread Naoto Sato
On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. >> There is already a factory method and a builder to return singletons, so >> there is no need to have constructors anymore unless one purposefully wants >> to

Re: RFR: 8282819: Deprecate Locale class constructors

2022-03-25 Thread Roger Riggs
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Stephen Colebourne
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from

Re: RFR: 8282819: Deprecate Locale class constructors

2022-03-25 Thread Roger Riggs
On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. > There is already a factory method and a builder to return singletons, so > there is no need to have constructors anymore unless one purposefully wants > to create

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 15:17:02 GMT, Stephen Colebourne wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > >

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Stephen Colebourne
On Fri, 25 Mar 2022 14:35:46 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]

2022-03-25 Thread Claes Redestad
> Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due > ZoneOffset::getRules allocating a new

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 14:52:09 GMT, Roger Riggs wrote: >> Done. >> >> Sadly it seems the smaller improvement I got on >> `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in >> `Instant.ofEpochSecond(sec, nanos)`: >> >> Benchmark Mode

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Roger Riggs
On Fri, 25 Mar 2022 14:28:41 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/time/ZoneRegion.java line 183: >> >>> 181: @Override >>> 182: /* package-private */ ZoneOffset getOffset(long epochSecond) { >>> 183: return >>>

Re: RFR: 8283683: Make ThreadLocalRandom a final class

2022-03-25 Thread Jaikiran Pai
On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` > class as `final`? Related JBS issue > https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 12:33:21 GMT, Richard Startin wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > >

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Claes Redestad
> Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due > ZoneOffset::getRules allocating a new

Re: RFR: 8283681: Improve ZonedDateTime offset handling [v2]

2022-03-25 Thread Claes Redestad
On Fri, 25 Mar 2022 14:09:03 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > >

Re: RFR: 8283683: Make ThreadLocalRandom a final class

2022-03-25 Thread Doug Lea
On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` > class as `final`? Related JBS issue > https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too

Re: RFR: 8283683: Make ThreadLocalRandom a final class

2022-03-25 Thread Jaikiran Pai
On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` > class as `final`? Related JBS issue > https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too

Re: RFR: 8283681: Improve ZonedDateTime offset handling

2022-03-25 Thread Roger Riggs
On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy

RFR: 8283683: Make ThreadLocalRandom a final class

2022-03-25 Thread Jaikiran Pai
Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. tier1, tier2 and tier3 tests have been run with this

RFR: 8283681: Improve ZonedDateTime offset handling

2022-03-25 Thread Claes Redestad
Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object

Re: RFR: 8283681: Improve ZonedDateTime offset handling

2022-03-25 Thread Richard Startin
On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy

Re: RFR: 8240903: Add a regression test for JDK-8240734 [v3]

2022-03-25 Thread Alan Bateman
On Fri, 25 Mar 2022 05:16:28 GMT, Dongbo He wrote: >> This creates a regression test for >> [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was >> once blocked >> by a time stamp issue which has been resolved by: [JDK-8276766 >>

CompletionStage#{handle, whenComplete}[Async] should provide (Function, Function, ..) and (Consumer, Consumer, ..) overloads

2022-03-25 Thread Petr Portnov
Hi there! CompletionStage and its subclasses (i.e. CompletableFuture) represent an either successful (T) or failed (Throwable). These states are logically mutually exclusive as can also be seen from the documentation [1]: > Two method forms (handle and whenComplete) support unconditional >

Re: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar [v2]

2022-03-25 Thread Lance Andersen
On Thu, 24 Mar 2022 20:59:20 GMT, Brent Christian wrote: >> Please review this change to the java/util/prefs/AddNodeChangeListener.jar >> test. >> >> Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh >> Preferences on each test run, MacOS does not seem to honor

Re: Thread::getId final method

2022-03-25 Thread Rafael Winterhalter
Thanks for the info! For the use case I found, the override does not make any sense and a final method would have allowed for an easy fix if that would have been the way this was discovered. I think the method would make sense even before Loom. The overridable getter is also used in some MX

Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes

2022-03-25 Thread Alan Bateman
On 25/03/2022 09:37, Bernd Eckenfels wrote: I wonder should the CSR not describe what’s the advantage of this change is and what the compatibility problems are and why they don’t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of

Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes

2022-03-25 Thread Bernd Eckenfels
I wonder should the CSR not describe what’s the advantage of this change is and what the compatibility problems are and why they don’t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see

Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes

2022-03-25 Thread Jaikiran Pai
On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time > IllegalFormatException. > > Please also review the companion CSR: > https://bugs.openjdk.java.net/browse/JDK-8283669 Marked as reviewed by jpai (Committer). - PR:

Re: Thread::getId final method

2022-03-25 Thread Alan Bateman
On 25/03/2022 08:18, Rafael Winterhalter wrote: Hello, I was recently debugging an issue where threads' ids were used to identify an origin thread. The issue turned out to be that the getId method was overridden to return 0 for a row of threads in unrelated code, what broke that processing. I

Re: RFR: 8282162: [vector] Optimize vector negation API

2022-03-25 Thread Jie Fu
On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu wrote: >>> Note that in terms of Java semantics, negation of floating point values >>> needs to be implemented as subtraction from negative zero rather than >>> positive zero: >>> >>> double negate(double arg) {return -0.0 - arg; } >>> >>> This is to

Thread::getId final method

2022-03-25 Thread Rafael Winterhalter
Hello, I was recently debugging an issue where threads' ids were used to identify an origin thread. The issue turned out to be that the getId method was overridden to return 0 for a row of threads in unrelated code, what broke that processing. I do now wonder if it would be a good idea to offer

Re: [External] : Re: jpackage Windows support for 4 digits version

2022-03-25 Thread Sverre Moe
Hi, I was hoping something could be done to allow 4 fields in the version on Windows when using jpackage. Even though Windows will ignore the fourth component when installing, that is ok, but if we could build just build an EXE with 4 fields version. If by some configuration with jpackage, or the

Re: [External] : Re: jpackage Windows support for 4 digits version

2022-03-25 Thread David Holmes
On 25/03/2022 5:14 am, Alexey Semenyuk wrote: Hi Sverre, Oh, I misunderstood the problem. I though the issue was with parsing WiX version string, but the problem is that jpackage doesn't like the value of --version cli parameter. On windows this value should satisfy constrains of MSI