DoubleBuffer.compareTo is not anti-symmetric

[Martin Buchholz]

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

On Fri, Nov 20, 2009 at 13:15, Alan Bateman <Alan.Bateman at sun.com> wrote:
>
> Martin Buchholz wrote:
>>
>> This is a bug report.
>>
>> import java.nio.*;
>>
>> public class BufferCompare {
>>    public static void main(String[] args) {
>>        DoubleBuffer b1 = DoubleBuffer.wrap(new double[] { Double.NaN });
>>        DoubleBuffer b2 = DoubleBuffer.wrap(new double[] { 1.0 });
>>        System.out.printf("%b%n", b1.compareTo(b2));
>>        System.out.printf("%b%n", b2.compareTo(b1));
>>    }
>> }
>> ==> javac -source 1.6 -Xlint:all BufferCompare.java
>> ==> java -esa -ea BufferCompare
>> true
>> true
>>
>> Is there any chance we might be allowed
>> to fix this violation of the Comparable contract?
>> If so, I volunteer to do so.
>>
> Oops, I assume NaN was overlooked. I can't think of any reasons not to fix this, at least for for jdk7. Changing compareTo to invoke $Type$.compare(v1, v2) sounds like a good start.  I'll create a bug for you shortly.
>
> -Alan.