On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti <rgiulie...@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
