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 https://bugs.openjdk.java.net/browse/JDK-8
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: f520b4
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 Bateman](mailto:alan.bate.
> 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 ca
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 ZoneId::getOffse
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 heavy
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 allo
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: (lo
> 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 ca
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 heavy
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
https://bugs.openjdk.java.net/browse/JDK-8283707
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 the
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 heavy
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
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 crea
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 `i
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 heavy
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 `i
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
>
> src/java.base/share/classes/java/time/Zon
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 heavy
> 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 ZoneR
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
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
>>> getRules().getOffset(Instant.ofEpochSecond
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 https://bugs.openjdk.java.net/browse/JDK-8
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
>
> test/micro/org/openjdk/bench/java/time/GetYea
> 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 ZoneR
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
>
> src/java.base/share/classes/java/time/ZoneRegion.
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 https://bugs.openjdk.java.net/browse/JDK-8
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 https://bugs.openjdk.java.net/browse/JDK-8
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 allo
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 chan
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
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 allo
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
>> ](https://bugs.openjdk.java.net/browse/JDK
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
> comput
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 this,
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 beans
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 break
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 t
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: h
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 d
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 h
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 a
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
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 ProductVe
45 matches
Mail list logo