On Apr 8 2014, at 01:03 , Paul Sandoz <paul.san...@oracle.com> wrote:
> > 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? Probably even if the dependence is implicit such as expecting a particular iteration order > or do you think it would be possible to change that? I requested fixing the compareTo long ago (back when I was a mere user of the JDK) and was told that it could not be changed. > 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. I agree that most code would probably be fine. I worry though that there will be cases that either explicitly or implicitly depend upon current ordering. Surprisingly there a lot of cases where UUIDs are created using the UUID(long, long) constructor with non-random data such as incrementing numbers: UUID myUUID = new UUID(SOME_CONSTANT, atomicSerial.incrementAndGet()); This usage exists, I believe, because we haven't provided direct support for MAC version UUIDs. Unfortunately the UUID(long,long) constructor does not check that the UUID constructed is even valid and usually they are not. This usage, while egregious, is common. These people would probably be impacted by changes in ordering. >> 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. If it were up to me only the time and DCE UUIDs would be comparable, there's no ordering relationship for other versions. The comparators I've considered adding would only allow comparisons within the same version. >> 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. Any change to the ordering of the compareTo would have to happen in a major version if at all. I am very reluctant to change this behaviour when providing alternative comparators might just be a better choice. Mike
