On Wed, 1 Oct 2025 17:22:39 GMT, Kieran Farrell <[email protected]> wrote:

>> With the recent approval of UUIDv7 
>> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new 
>> static method UUID.timestampUUID() which constructs and returns a UUID in 
>> support of the new time generated UUID version. 
>> 
>> The specification requires embedding the current timestamp in milliseconds 
>> into the first bits 0–47. The version number in bits 48–51, bits 52–63 are 
>> available for sub-millisecond precision or for pseudorandom data. The 
>> variant is set in bits 64–65. The remaining bits 66–127 are free to use for 
>> more pseudorandom data or to employ a counter based approach for increased 
>> time percision 
>> (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>> 
>> The choice of implementation comes down to balancing the sensitivity level 
>> of being able to distingush UUIDs created below <1ms apart with performance. 
>> A test simulating a high-concurrency environment with 4 threads generating 
>> 10000 UUIDv7 values in parallel to measure the collision rate of each 
>> implementation (the amount of times the time based portion of the UUID was 
>> not unique and entries could not distinguished by time) yeilded the 
>> following results for each implemtation:
>> 
>> 
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>> 
>> 
>> Performance tests show a decrease in performance as expected with the 
>> counter based implementation due to the introduction of synchronization:
>> 
>> - random-byte-only   143.487 ± 10.932  ns/op
>> - higher-precision      149.651 ±  8.438 ns/op
>> - counter-based         245.036 ±  2.943  ns/op
>> 
>> The best balance here might be to employ a higher-precision implementation 
>> as the large increase in time sensitivity comes at a very slight performance 
>> cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove old test case reference

As Bokken highlighted, I think it might be worth adding a method (similar to 
the below) to extract the timestamp from v7 UUIDs?


public long epochMilliTimestamp() {
    if (version() != 7) {
        throw new UnsupportedOperationException("Not a version 7 UUID");
    }
    return (mostSigBits >>> 16) & 0xFFFFFFFFFFFFL;
}


Regarding, the issues around comparison, as mentioned I think would it would be 
worth updating the current `compareTo` doc to identify that the implmentation 
uses signed long comparison and may not provide lexographical sorting in align 
with the rfc which can be problmetaic for time based UUIDs and also to add a 
seperate instance method but with lexographical sorting using unsigned 
comparrsion.

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

PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3360534618

Reply via email to