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.
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
On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 "typ
On Apr 8, 2014, at 1:03 AM, Paul Sandoz wrote:
>
> On Apr 7, 2014, at 7:23 PM, Mike Duigou wrote:
>
>> 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 additio
I am targeting to have the performance improvements you contributed to UUID
into 8u40 (around the end of the year). I expect to contribute the work into
OpenJDK 9 in June-Julyish.
Mike
On Apr 8 2014, at 09:34 , Steven Schlansker wrote:
>
> On Apr 8, 2014, at 1:03 AM, Paul Sandoz wrote:
>
>
On Apr 8 2014, at 01:03 , Paul Sandoz wrote:
>
> On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 val
On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote:
>> 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 yo
On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote:
> On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote:
>
> That seems a terribly broken usage of UUID for 128 bit numbers or a pair of
> signed 64 bit numbers :-)
>
> Part of me thinks we should not be supporting such broken usage. Might be
> worth g
On 04/10/2014 08:21 PM, Steven Schlansker wrote:
On Apr 9, 2014, at 2:21 AM, Paul Sandoz wrote:
On Apr 8, 2014, at 9:15 PM, Mike Duigou wrote:
That seems a terribly broken usage of UUID for 128 bit numbers or a pair of
signed 64 bit numbers :-)
Part of me thinks we should not be supportin
On Apr 11, 2014, at 8:54 AM, Peter Levart 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.
10 matches
Mail list logo
