On Thu, 9 Oct 2025 17:13:23 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:
> 
>   update spec

src/java.base/share/classes/java/util/UUID.java line 74:

> 72:  *
> 73:  * @spec https://www.rfc-editor.org/rfc/rfc9562.html
> 74:  *      RFC 9562 Universally Unique IDentifiers (UUIDs)

Hello Kieran, In this class there's a pre-existing `variant()` method. On that 
method, the javadoc still refers to RFC-4122. Please update `<a href...` link 
in that javadoc to use RFC-9562 like you have done here and please also remove 
the `@spec` from that method's javadoc. I don't think it's needed there, given 
that it will link to the RFC as well as this class level `@spec`

test/jdk/java/util/UUID/UUIDTest.java line 150:

> 148:     }
> 149: 
> 150:     private static void epochMillis_userInputTest() {

Nit - it might be better to name this method `testEpochMillisTimestamp()`

test/jdk/java/util/UUID/UUIDTest.java line 159:

> 157:             }
> 158:         } catch (Exception e) {
> 159:             throw new AssertionError("Unexpected exception with 
> timestamp " + timestamp + ": " + e);

Please pass the original exception `e` as the cause of this AssertionError, 
something like:

throw new AssertionError("Unexpected exception with timestamp " + timestamp, e);


That will help debug any failures if at all they happen. Same comment for a few 
other places in this new test method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2452711341
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2452716220
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2452715029

Reply via email to