JDK-7025832 : java.lang.UUID compareTo() does not do an unsigned compare
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6u24
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_7
  • CPU: x86
  • Submitted: 2011-03-09
  • Updated: 2012-09-06
  • Resolved: 2011-03-09
Description
FULL PRODUCT VERSION :
1.6.0_22

ADDITIONAL OS VERSION INFORMATION :
Windows 7

A DESCRIPTION OF THE PROBLEM :
Found that UUID.compareTo() was producing results inconsistent other UUID comparison implementations including the rfc4122 sample implementation.  Examined source:

public int compareTo(UUID val) {
    // The ordering is intentionally set up so that the UUIDs
    // can simply be numerically compared as two numbers
    return (this.mostSigBits < val.mostSigBits ? -1 :
            (this.mostSigBits > val.mostSigBits ? 1 :
             (this.leastSigBits < val.leastSigBits ? -1 :
              (this.leastSigBits > val.leastSigBits ? 1 :
               0))));
}

It appears that, because mostSigBits and leastSigBits are stored as java longs, that this is a signed comparison when these values should be compared unsigned.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Perform bytewise comparison of UUID value.

Comments
PUBLIC COMMENTS Though the bug is accurate that the compareTo implementation is not consistent with other implementations the Java UUID.compareTo() method must remain consistent among versions of Java. The compareTo() function is used primarily for sorting and the sort order of UUIDs must remain stable from version to version of Java.
09-03-2011

EVALUATION As the submitter suggests the comparison is done using signed arithmetic. It would be a significant problem to alter the behaviour of the UUID.compareTo() method as it would, principally, alter the order of sorting. Sorts involving UUIDs must remain stable.
09-03-2011