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.