UUID.compareTo broken?

[Mike Duigou]

The issue is that the comparison is done upon the signed most significant and least significant long values.

At minimum UUIDs should be compared as if they were 128-bit unsigned values.

Beyond that, version (which is a "type" not a version) 1 and 2 UUIDs (time based and DCE), should have a more sophisticated comparison which orders the UUIDs by their creation time.

This is one of those cases where sloppiness/laziness/ignorance in the original implementation version sticks around forever.

We could provide static methods to return appropriate comparators for version 1 and version 2 UUIDs--I've actually written them before for other projects.

I also note that UUID does not currently support version 5, SHA-1, which it should.

I am hoping to do other performance work on UUID within the scope of Java 9. Adding additional Comparators would fit right in with that.

Mike

On Apr 7 2014, at 03:49 , Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> https://github.com/cowtowncoder/java-uuid-generator
> 
> "JDK's java.util.UUID has flawed implementation of compareTo(), which uses naive comparison of 64-bit values. "
> 
> Anyone familiar with the JDK UUID implementation care to comment?
> 
> Paul.