All of the classes that extend java.lang.Number also implement
java.lang.Comparable. As all numbers are comparable, shouldn't 
the class Number implement Comparable?

N/A

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.

  xxxxx@xxxxx   2001-11-01

The reasoning is correct but I disagree with the approach.

NaN (which is one of the
motivational cases) is not Comparable. However, when you look up the behavior of
compareTo() in Float -- no such special condition exists for the case
of NaN

While some numbers are not comparable, I argue that all REAL numbers are comparable. So, Double d =
10.12 and Integer x = 11 ARE comparable. X is clearly larger.

For me, it seems that a better approach would be to have Number to
implement Comparable in the class signature but not actually DO the
implementation. Or, alternatively, supply an intermediary class like 'RealNumber extends Number implements Comparable' That way, in the event of NaN and such, implementing
methods can simply throw exceptions (which seems far more appropriate
than what Float.compareTo(Float.NaN) produces now -- which is

       int result = new Float(10).compareTo(Float.NaN);
        System.out.println(result);

-1

Only special number cases are not comparable. 

Christian Bongiorno