On Wed, 2 Jul 2025 15:59:47 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> 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. At a minimum, the javadoc should specify the parameters used to generate UUID instances so that an application can decide for itself whether it meets the application's requirements. Note also the tradeoff between performance and rate of generation. To expose higher granularity (than milli-seconds) would require a different API and synchronization. Applications are also free to specify and implement their own algorithm for creating the 128 bits and create UUID instances with the UUID(long, long) or UUID(byte[]) constructors. The system time and nano-time are readily available. There is little information about application requirements to inform the API. If additional operational requirements come to light, a new factory method can be implemented to meet the need. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2180456180
