DoubleBuffer.compareTo is not anti-symmetric

Alan Bateman Alan.Bateman at Sun.COM
Tue Nov 24 03:26:28 PST 2009

Martin Buchholz wrote:
> :
> Yes, you're right - a sad situation.
> I'd like to change the behavior so that e.g.
> DoubleBuffer.equals compares corresponding elements using Double.equals
> and
> DoubleBuffer.compareTo compares corresponding elements using Double.compareTo
> but maybe that's too bold a step for the JDK.
I think so as we don't know what/who it might break.

> I can also do the minimal patch to compareTo
> that considers NaN as greater than any other value.
> But that would be introducing yet another
> way of comparing floating point values.
> Hmmmmm....I'm sadly talking myself into taking that
> conservative but disagreeable decision.
> OK. Done.
It's unfortunate but I don't see another solution that won't cause more 

A few comments on the current webrev:

Kelly renamed to a few weeks ago 
(just noticed that your webrev is against

The clarification to the equals javadoc is mostly okay. I think I'd 
prefer the second sentence (currently starting with "Unlike ...") to go 
something like "Note that positive zero and negative zero compare equal 
and so this method differs to $Fulltype$#equals".

Minor nit is that you need a space after <p> to be locally consistent 
(same issue in compareTo).

The clarification to the compareTo javadoc is also okay except that the 
sentences are long - how about this as an alternative:

"This method differs to the Java language comparison operations in that 
it considers $Fulltype$.NaN to be equal to itself and greater than all 
other $type$ values (including $Fulltype$.POSITIVE_INFINITY).  As 
positive zero and negative zero compare equals so then it differs to the 

Thanks for adding a new test to I think you might have 
left a few debug messages that you might want to remove.

> :
>> Would you have time to add a test to
>> test/java/nio/Buffer/ for this? (you need to run
>> to re-generate the tests when you change this).
> Done.
> Unfortunately, this change is starting to grow:
> I removed the dangerous "rm -rf build" from
Looks like it was left over from other changes.

> It made no sense to me that "char" would have a fulltype of
> "character", but "int" didn't have a fulltype of "integer".
> I fixed that, and that allowed $Fulltype$ to be usable in
> the source.
>  case $type in
>    char)  fulltype=character;;
> +  int)   fulltype=integer;;
>    *)     fulltype=$type;;
>  esac
I can't see any problem doing this but can you compare the generated 
code to make sure it is the same?


More information about the nio-dev mailing list