RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]

[Jaikiran Pai]

On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs <rriggs at 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