On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs <[email protected]> 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
