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

[Kieran Farrell]

On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, I think 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
>
> Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this requirement. There are some methods described in §6.2 to help ensuring monotonicity.
> 
> While it is true that the 74 bits of randomness help in creating unique ID with high probability, the requirements for the timestamp part in UUID Version 7 seem more restrictive than just uniqueness.

Hi Jaikiran, You are correct in that the current implementation only supports uniqueness among time clashes and not monotonicity. Although section 5.7 UUID version 7 states that adding monotonic or extra precision bits is optional and that the millisecond portion along with the random bits is sufficient, section 6.2 does state: 

> Take care to ensure UUIDs generated in batches are also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the creation order of those one thousand UUIDs 
     
The use of 'should' here makes it seem like this is a strong recommendation rather than a mandate. Regardless, it might be benifical to better satisfy this guidance. Since we don't currently have access to higher precision time, updating the implementation to include a dedicated counter would be the only viable approach, and comes at the cost of performance.

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

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