Instant.now(Clock) and InstantSource

[Kurt Alfred Kluever]

Hi folks,

It feels a bit strange that you can't pass an `InstantSource` to
`Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
"useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
propose one of the following API changes:

1) adding `Instant.now(InstantSource)`
2) deprecating `Instant.now(Clock)` in favor of `clock.instant()`

(I believe removing `Instant.now(Clock)` would be binary compatible, so
that's not an option, right?)

There's also a related discussion about adding an InstantSource-based
static factory method to the "local" types (e.g.,
`LocalDate.now(InstantSource, ZoneId)`). However, I always avoid using the
static factories on those types and have been quite happy with the fluent
pattern instead (e.g., `instantSource.instant().atZone(...).toLocalDate()`).

Thoughts?

-- 
kak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240603/ca2a4f73/attachment.htm>