On Apr 7, 2014, at 7:23 PM, Mike Duigou <mike.dui...@oracle.com> wrote:
> 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. > Thanks. > 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. > For the case of incorrect signed comparison is it sticking around because there is code dependent on the current broken behaviour? or do you think it would be possible to change that? i have my suspicious that code dependent compareTo may not break if the total ordering changes, since many cases are likely to be for randomly generated UUIDs. > 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. > It would be nice to just have one compareTo that does the right thing based of the UUID types being compared. > 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. > OK, although it might be nice to bash this on the head sooner? as it might be possible to get into an 8u release depending on what we conclude about backwards compatibility. Paul.
