UUID.compareTo broken? (original) (raw)

Mike Duigou mike.duigou at oracle.com
Mon Apr 7 17:23:38 UTC 2014

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.

More information about the core-libs-dev mailing list