On Wed, 2 Jul 2025 10:08:53 GMT, Kieran Farrell <kfarr...@openjdk.org> wrote:

>> 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.

RFC 2119 defines the intention for the word SHOULD, allowing some optionality.

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

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

Reply via email to