UUID.compareTo broken?

[Paul Sandoz]

On Apr 11, 2014, at 8:54 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> Code that relies on UUIDs to have a "natural" order, say "chronological", is relying on being given the particular type of UUIDs that have the time built-in. When given mixed-type or non-time-based UUIDs, such code will break. The purpose of UUID schemes is generating globally unique identifiers, not interpreting them. Various types exist just because it's practical to generate UUIDs differently in different contexts.

Good point, the bias is towards producers, but still i can imagine time-based UUIDs are quite useful for consumers and i think implicitly such users would reasonably expect them to be ordered in some manner based on the time.


> Programs should not try to extract business information from UUIDs (except probably for hunting down virus authors: http://en.wikipedia.org/wiki/Melissa_%28computer_virus%29). So I think a good general-purpose compareTo() method should try to discourage such usage for example by reversing the bits of the UUID value before comparing. This would also make algorithms that order UUIDs for facilitating quick access (B-Tree, Red-Black-Tree, ...) happier.
> 

Interesting, i suppose if those N values are randomly shuffled then added it may get close to reversed bit result, i should probably try it :-)

Paul.