On Wed, 10 Sep 2025 19:46:12 GMT, Kieran Farrell <kfarr...@openjdk.org> 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 method name Hello Roger, > The view that the application needs to take overall responsibility for the > needed semantics could be reinforced by removing the convenience method > `epochMilliUUID()` leaving it to the application to supply the value to be > encoded as the milliseconds in the UUID. Do you mean getting rid of the `epochMillis()` (the no-arg one) method from this PR? My initial thought was that just providing an API which constructs a UUIDv7 instance from a user provided value isn't too useful, but then reading your note about: > The API simplifies the construction of a V7 UUID but does not make the more > comprehensive guarantees. I think that could/should be considered a separate initiative. It would be beneficial to layer that Java support for a fully supported V7 on top of support by the operating system function. I don't think it can be delivered without OS support. I agree with what you are saying. The level of monotonicity I had in mind was per JVM lifetime, but like you note, it could be bigger: > Given the full scope of monotonicity including across application and runtime > restarts is a much larger requirement. If we drop the `epochMillis()` (the no-arg one) method from this PR (which I think is what you meant), then I think it's reasonable. With that, the timestamp computation that's being introduced in this PR will be gone completely. What we will end up with is just one new API which allows applications to pass a `long` value (representing a timestamp) which we use to construct a `UUID` instance that is structurally UUIDv7 version. With an appropriate javadoc for the method and maybe a `@apiNote`, I think we can convey that the implementation of this method isn't responsible for the additional semantics expected of a UUIDv7 instance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3328624631
