DoubleBuffer.compareTo is not anti-symmetric
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
> 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 X-Buffer.java to X-Buffer.java.template a few weeks ago
(just noticed that your webrev is against X-Buffer.java).
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 Basic-X.java. 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/Basic-X.java.template for this? (you need to run
>> genBasic.sh to re-generate the tests when you change this).
> Unfortunately, this change is starting to grow:
> I removed the dangerous "rm -rf build" from genBasic.sh
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;;
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