DoubleBuffer.compareTo is not anti-symmetric

Martin Buchholz martinrb at
Fri Nov 20 18:26:44 PST 2009

I have a webrev for y'all at

6666666: (bf) Improve floating-point buffer comparison

Describe the exact behavior of {Double,Float}Buffer.{equals,compareTo}.

Fix the behavior of
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.


On Fri, Nov 20, 2009 at 13:15, Alan Bateman <Alan.Bateman at> 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
>> ==> 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.

More information about the nio-dev mailing list