Why doesn't java.lang.Number implement Comparable?
This question already has an answer here:
It's worth mentioning that the following expression:
new Long(10).equals(new Integer(10))
is always false , which tends to trip everyone up at some point or another. So not only can you not compare arbitrary Number s but you can't even determine if they're equal or not.
Also, with the real primitive types ( float , double ), determining if two values are equal is tricky and has to be done within an acceptable margin of error. Try code like:
double d1 = 1.0d;
double d2 = 0.0d;
for (int i=0; i<10; i++) {
d2 += 0.1d;
}
System.out.println(d2 - d1);
and you'll be left with some small difference.
So back to the issue of making Number Comparable . How would you implement it? Using something like doubleValue() wouldn't do it reliably. Remember the Number subtypes are:
Byte ; Short ; Integer ; Long ; AtomicInteger ; AtomicLong ; Float ; Double ; BigInteger ; and BigDecimal . Could you code a reliable compareTo() method that doesn't devolve into a series of if instanceof statements? Number instances only have six methods available to them:
byteValue() ; shortValue() ; intValue() ; longValue() ; floatValue() ; and doubleValue() . So I guess Sun made the (reasonable) decision that Number s were only Comparable to instances of themselves.
For the answer, see Java bugparade bug 4414323. You can also find a discussion from comp.lang.java.programmer
To quote from the Sun response to the bug report from 2001:
All "numbers" are not comparable; comparable assumes a total ordering of numbers is possible. This is not even true of floating-point numbers; NaN (not a number) is neither less than, greater than, nor equal to any floating-point value, even itself. {Float, Double}.compare impose a total ordering different from the ordering of the floating-point "<" and "=" operators. Additionally, as currently implemented, the subclasses of Number are only comparable to other instances of the same class. There are other cases, like complex numbers, where no standard total ordering exists, although one could be defined. In short, whether or not a subclass of Number is comparable should be left as a decision for that subclass.
in order to implement comparable on number, you would have to write code for every subclass pair. Its easier instead to just allow subclasses to implement comparable.
链接地址: http://www.djcxy.com/p/91928.html上一篇: 标准api中是否存在自然比较器？