DoubleBuffer.compareTo is not anti-symmetric

[Alan Bateman]

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

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

-Alan.