On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/UUID.java line 107: >> >>> 105: >>> 106: private static long monotonicMS() { >>> 107: return ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000; >> >> Hello Kieran, the `System.nanoTime()` specifies: >> >>> This method provides nanosecond precision, but not necessarily >> nanosecond resolution (that is, how frequently the value changes) - no >> guarantees are made except that the resolution is at least as >> good as that of {@link #currentTimeMillis()}. >> >> Then `System.currentTimeMillis()` specifies: >> >>> Note that while the unit of time of the return value is a millisecond, >> the granularity of the value depends on the underlying >> operating system and may be larger. For example, many >> operating systems measure time in units of tens of >> milliseconds. >> >> Would that then mean that there's no guarantee here on this line that >> multiple sequential calls to `System.nanoTime()` will not return the same >> value and thus the breaking the monotonic guarantee of this method? > > The uniqueness comes not just from the timestamp but also from the random > data in the other bytes that are generated for each new UUID. Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, it has much stricter expectations about monotonocity (the first 48 bits) too. For example, the following sections: https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177888554