On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs <rri...@openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 107:
>> 
>>> 105: 
>>> 106:     private static long monotonicMS() {
>>> 107:         return ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000;
>> 
>> Hello Kieran, the `System.nanoTime()` specifies:
>> 
>>> This method provides nanosecond precision, but not necessarily
>> nanosecond resolution (that is, how frequently the value changes) - no
>> guarantees are made except that the resolution is at least as
>> good as that of {@link #currentTimeMillis()}.
>> 
>> Then `System.currentTimeMillis()` specifies:
>> 
>>> Note that while the unit of time of the return value is a millisecond,
>> the granularity of the value depends on the underlying
>> operating system and may be larger.  For example, many
>> operating systems measure time in units of tens of
>> milliseconds.
>> 
>> Would that then mean that there's no guarantee here on this line that 
>> multiple sequential calls to `System.nanoTime()` will not return the same 
>> value and thus the breaking the monotonic guarantee of this method?
>
> The uniqueness comes not just from the timestamp but also from the random 
> data in the other bytes that are generated for each new UUID.

Hello Roger, that's true about the uniqueness semantics. However, from what I 
understand of RFC-9562, on which this new API is based, it has much stricter 
expectations about monotonocity (the first 48 bits) too. For example, the 
following sections:

https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations
https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177888554

Reply via email to