DoubleBuffer.compareTo is not anti-symmetric

[Martin Buchholz]

On Sun, Nov 22, 2009 at 07:41, Alan Bateman <Alan.Bateman at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> I have a webrev for y'all at
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/DoubleBuffer/
>>
>> 6666666: (bf) Improve floating-point buffer comparison
>>
>> Describe the exact behavior of {Double,Float}Buffer.{equals,compareTo}.
>>
>> Fix the behavior of
>> {Double,Float}Buffer.compareTo
>> so that it satisfies the Comparable contract.
>>
>> I'd also like to fix the behavior of  {Double,Float}Buffer.equals to be
>> compatible with  {Double,Float}.equals, but the proposed change assumes
>> that we are stuck with the historic behavior and should simply
>> document it.
>>
>> Martin
>>
>
> I've created this bug to track this:
>  6903754: (bf) Improve floating-point buffer comparison
>
> I haven't had time yet to fully digest the proposal (at least, from an
> initial glance, the 0.0/-0.0 case where it looks like equals and compareTo
> will now be inconsistent).

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 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.

 One passing comment on the javadoc update is that
> the clarification as to how equals behaves might be better to be part of
> item 3 rather than starting a new item (as it logically follows).

?! It does not start a new <li> - just a new <p>

> Also given
> that these are buffers of primitive types then an alternative would be to be
> explicit as to how it it differs from the Java Language == operator and do a
> "see also" for Double#equals(double)? Minor comment on compareTo is that
> "invoking" would be more consistent than "using".

Changed.

>
> 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).

Done.

Unfortunately, this change is starting to grow:

I removed the dangerous "rm -rf build" from genBasic.sh

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

Much bigger webrev now at
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/DoubleBuffer/

Martin

> -Alan.
>
>
>
>
>
>
>
>
>
>