Current thinking about the future nullability of java.time.Duration

[Caleb Cushing]

And we think there might be a few more things although I'm not sure they're
types that would opt in to this. There are several methods that I can
"think" of that will throw errors if you pass them nulls. For example
Optional.of would make no sense not to have its parameter as non null.
Although maybe they would opt for that so people can catch the exception
which I find ridiculous

On Fri, Jan 10, 2025, 8:03 AM Jean-Noël Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> After your comments, I realize that, except primitive types, no type in
> the JDK will opt-in to become a null-restricted value class type because
> this would be an incompatible change.
> Future added types may opt into being null-restricted value types from the
> get go.
> It means`null` can be used today with confidence it won't go away in the
> future.
>
> > As currently specified, there is no clean Duration value that could be
> used as a sentinel (alternative to null) except in some application
> specific use.
>
> That's true.
> I currently have a `public static final Duration UNLIMITED =
> Duration.ofSeconds(Long.MAX_VALUE);`, but this is not really a sentinel,
> and any other `Duration.ofSeconds(Long.MAX_VALUE)` is equal to it. So it's
> not a problem.
>
> Thanks all!
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250110/2eeda600/attachment.htm>