RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v4]

[kieran-farrell]

On Thu, 29 May 2025 18:30:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. “timestamp must be Unix time in milliseconds.” As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). 
>> 
>> Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7?
>
> RFC 9562 does not indicate any relation between the timestamp value and the "current" time.
> So yes, document it as the Unix Epoch, milliseconds since 1970. 
> There could be plenty of use cases for creating a UUID from some other source of time, like the timestamp of a file or a time field in a database.

Latest update:

- changed to millis + randomByte allocation implementation
- updated method to take user provided timestamp
- added API which delegates to method with current timestamp if no user input provided
- validated user input (this is far from fool proof, but prevents negative time values and some other time formats)
- updated method name to unixEpochTimeMillis
- added a note with ref to rfc to make user aware of time format required for rfc compliance
- added test coverage

Updated benchmark:


Benchmark                          Mode  Cnt    Score    Error  Units
UUIDBenchmark.unixEpochTimeMillis  avgt   25  138.076 ± 11.438  ns/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2115691663