On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato wrote:
>> A new method on Instant to return the duration `until` another Instant is
>> suggested per the following discussion thread:
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>>
>> A CSR has also been drafted.
>
>
On Thu, 21 Dec 2023 21:51:10 GMT, Eamonn McManus wrote:
> Multiplying with `*` never produces `ArithmeticException`, so the catch in
> the existing code is never triggered. `Math.multiplyExact` does produce
> `ArithmeticException` if the multiplication overflows. So we can use tha
On Fri, 22 Dec 2023 23:25:35 GMT, Raffaello Giulietti
wrote:
> Don't forget to update the copyright years in both files, please ;-)
Done. (I'm a bit surprised there isn't some sort of automated check if this is
a requirement.)
-
PR Comment: https://git.openjdk.org/jdk/pull/17181#
ication says.
>
> There is a small compatibility risk, in that code may have been relying on
> the previous silent overflow, and will now get an exception. But an exception
> is surely better than the nonsense results that overflow produces.
>
> Thanks to Kurt Kluever for the t
ication says.
>
> There is a small compatibility risk, in that code may have been relying on
> the previous silent overflow, and will now get an exception. But an exception
> is surely better than the nonsense results that overflow produces.
>
> Thanks to Kurt Kluever for the t
On Fri, 22 Dec 2023 09:07:31 GMT, Raffaello Giulietti
wrote:
>> Eamonn McManus has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments about the new test.
>
> test/jdk/java/sql/testng/tes
On Thu, 21 Dec 2023 21:51:10 GMT, Eamonn McManus wrote:
> Multiplying with `*` never produces `ArithmeticException`, so the catch in
> the existing code is never triggered. `Math.multiplyExact` does produce
> `ArithmeticException` if the multiplication overflows. So we can use tha
Multiplying with `*` never produces `ArithmeticException`, so the catch in the
existing code is never triggered. `Math.multiplyExact` does produce
`ArithmeticException` if the multiplication overflows. So we can use that, and
rethrow `IllegalArgumentException` as the specification says.
There i
On Wed, 8 Nov 2023 21:58:47 GMT, Eamonn McManus wrote:
> This change simply replaces "period" with "duration", or in one case replaces
> "period unit" with just "unit".
This pull request has now been integrated.
Changeset: 965ae72
This change simply replaces "period" with "duration", or in one case replaces
"period unit" with just "unit".
-
Commit messages:
- 8319753: Duration javadoc has "period" instead of "duration" in several
places
Changes: https://git.openjdk.org/jdk/pull/16573/files
Webrev: https://
On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus wrote:
> The existing logic uses nanosecond arithmetic to compute Duration.between.
> Since that can overflow for durations greater than 292 years, it has a
> try/catch that falls back to computing the seconds part and adjusting th
On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus wrote:
> The existing logic uses nanosecond arithmetic to compute Duration.between.
> Since that can overflow for durations greater than 292 years, it has a
> try/catch that falls back to computing the seconds part and adjusting th
The existing logic uses nanosecond arithmetic to compute Duration.between.
Since that can overflow for durations greater than 292 years, it has a
try/catch that falls back to computing the seconds part and adjusting that for
nanoseconds. However, exception handling is typically very expensive, s
On Thu, 28 Sep 2023 17:20:47 GMT, Eamonn McManus wrote:
> It looks to have been an oversight that `final` was omitted. The fields are
> never assigned after initialization. `final` leads to shorter bytecode.
This pull request has now been integrated.
Changeset: ecb5e8a0
Author:
> It looks to have been an oversight that `final` was omitted. The fields are
> never assigned after initialization. `final` leads to shorter bytecode.
Eamonn McManus has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unr
It looks to have been an oversight that `final` was omitted. The fields are
never assigned after initialization. `final` leads to shorter bytecode.
-
Commit messages:
- In `Pattern.Bound`, make some constants `static final`.
Changes: https://git.openjdk.org/jdk/pull/15967/files
We
On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus wrote:
> Instant.ofEpochMilli says this:
>
>
> @throws DateTimeException if the instant exceeds the maximum or minimum
> instant
>
>
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it
>
ly tested in
> [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84),
> which calls it with both those values.
Eamonn McManus has updated the pull request with a new target base due to a
merge or a
On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus wrote:
> Instant.ofEpochMilli says this:
>
>
> @throws DateTimeException if the instant exceeds the maximum or minimum
> instant
>
>
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it
>
On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus wrote:
> Instant.ofEpochMilli says this:
>
>
> @throws DateTimeException if the instant exceeds the maximum or minimum
> instant
>
>
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it
>
On Tue, 8 Feb 2022 17:23:38 GMT, Stuart Marks wrote:
> PR for Sequenced Collections implementation.
Yes, I think this `LinkedHashMap.keySet()` change is binary compatible but
source incompatible. Surely binary incompatibility would have been enough to
rule it out immediately. For the source co
On Thu, 9 Mar 2023 21:03:38 GMT, Roger Riggs wrote:
> You're picking on a fine point here that is data dependent, and there's not
> much value in changing it.
Could you elaborate on this a bit? The way I see it, the argument to
`ofEpochMillis` is a `long` with the same meaning as
`System.curr
Instant.ofEpochMilli says this:
@throws DateTimeException if the instant exceeds the maximum or minimum instant
But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does
not throw. That's already implicitly tested in
[`TestInstant`](https://github.com/openjdk/jdk/blob/a9d
23 matches
Mail list logo
