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
