On Wed, 29 Oct 2025 09:15:31 GMT, Pavel Rappo <[email protected]> wrote:
>>> We might soon have saturating addition functionality in >>> `java.time.Instant`; see: #27549 >> >> Great tip! 💯 I will hold this PR until #27549 gets merged, and use >> `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods. >> >>> I note that `jdk.internal.net.http.common.Deadline` also wants to have >>> saturating subtraction, and I wonder if that's really needed. It seems that >>> the two usages of the `minus` method in the codebase can be reimplemented >>> alternatively. In which case `Deadline` could delete `minus`. >> >> I also have my reservations regarding the rich, yet seldom used API surface >> of `Deadline`. But revamping it is out of the scope of this work. >> >>> Furthermore, if there's no need for saturating subtraction, do we need the >>> `Deadline` class? What does it provide, that `Instant` does not? >> >> In short, `Instant` is not necessarily generated using a >> monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid >> that ambiguity and guaranteed to be always monotonically-increasing. See >> [this conversation for >> details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686). > > @vy, `Instant.plusSaturating` is in the mainline: > https://github.com/openjdk/jdk/commit/2758c6fda2f774d98ef0c24535a7f7e9fc722379 I discussed this matter internally with @pavelrappo and @dfuch, and decided to keep the code as is, and not use the recently introduced `Instant::plusSaturating(Duration)`, because: 1. This will result in extra work for backports. 2. Not all `Deadline` methods can take advantage of `Instant::plusSaturating`, e.g., `::between`, `::until`, and `::plus(long,TemporalUnit)`. Instead of some using `Instant::plusSaturating` and some catching `DateTimeException | ArithmeticException`, settle on a single approach to ease the cognitive load. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3461414361
