Are there any plans to support type 5 UUIDs (which use SHA-1 instead of
MD5)? From https://en.wikipedia.org/wiki/Universally_unique_identifier:
"RFC 4122 recommends version 5 (SHA-1) over version 3 (MD5). This is
because it is believed that MD5 is more prone to collisions than SHA-1,
though MD5 is somewhat faster. The RFC warns against use of UUIDs of any
version as security capabilities."
Thanks,
Sean
On 4/27/26 4:35 AM, David Alayachew wrote:
Thanks for the (speedy!) responses @Alan Bateman <[email protected]> and
@Jaikiran Pai <[email protected]>. Once I get some time (no idea
when), I will do exactly that, unless someone beats me to it.
In the meantime, would it make sense for someone to create an entry for
this in the JBS? If nothing else, it would make this discussion (and
potential others) easier for finding later. The entry @Jaikiran Pai
<[email protected]> linked is related, but different, so making a new
JBS entry for this specifically makes sense to me.
On Mon, Apr 27, 2026, 4:23 AM Alan Bateman <[email protected]> wrote:
On 27/04/2026 03:04, Jaikiran Pai wrote:
Hello David,
On 27/04/26 7:21 am, David Alayachew wrote:
Hello @core-libs-dev <[email protected]>,
Today was the first time I used the UUID library past
UUID.randomUUID() and
UUID.fromString(String).
I saw that UUID.ofEpochMillis(long timestamp) has the ability to
create a
UUID version 7 UUID -- a time-based UUID! Great, I also see that
there is a
UUID.timestamp() method, can I use that to extract the timestamp from
it?
Sadly, no. The UUID.timestamp() method is reserved for UUID version 1,
whereas UUID.ofEpochMillis(long timestamp) generates UUID version 7.
Ok, fair, the documentation is clear. But why can't we just add that
functionality to UUID.timestamp()? It's not that complex.
This and other similar questions were discussed during the review of
https://bugs.openjdk.org/browse/JDK-8334015. The PR here
https://github.com/openjdk/jdk/pull/25303 (or its corresponding
mailing list thread in core-libs-dev) has all those discussions. For
this specific question, the discussion is here
https://mail.openjdk.org/pipermail/core-libs-dev/2025-September/152621.html
Right, type 1 and 7 have different epochs and granularity so
UUID::timestamp has to throw when not type 1.
A method that returns an Instant could be feasible but would require
working some examples to check for surprises and hazards.
-Alan
