JDK-6583551 : compare numbers of different Number classes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 7
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-07-20
  • Updated: 2010-04-04
  • Resolved: 2007-07-20
Related Reports
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Instances of Number subclasses (such as Byte, Short, Integer, Long, Float, Double, BigInteger, BigDecimal) are comparable with instances of the same class, but are not comparable with instances of the other Number subclasses. So this RFE is about new class, say, java.util.NumberComparator, which extends java.util.Comparator<Number> and is able to compare instances of different Number subclasses. The comparison has to be precise (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6582946)


JUSTIFICATION :
NumberComparator could be useful in cases when instances of different Number subclasses is used or expected at the same time. For example, look at class javax.swing.RowFilter.NumberFilter

Comments
EVALUATION The requested functionality is ill-posed. Different subclasses of Number have nothing to do with one another other than they all call be converted in primitive types. (In retrospect, the Number class would have been better as an interface.) For the Number subclasses that are part of the JDK it would be feasible to do this by downcasting and converting the inputs to BigDecimal, making suitable accomodations for floating-point NaN and infinity values that aren't representable as BigDecimal, since a BigDecimal can exactly represent any finite value in the other types. However, anyone can extend Number to make, for instance, Interval, Complex, Imaginary, and Quaternion types. Mathematically complex numbers form an unordered field so such a type might not even by Comparable<Complex>. How should my quaternion compare to your imaginary number? Coverting different Numbers to, say, long and double, and doing comparisions on those values is tricky even when sensible and not alsays sensible. (Is longValue 0 because the number is 0 or because the number is Double.NaN? ...) Closing as not a bug.
20-07-2007