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.san...@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.

Reply via email to