JDK-4329937 : Boolean doesn't implement comparable: can't sort it into a JTable
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.1,1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2000-04-12
  • Updated: 2017-05-16
  • Resolved: 2003-08-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Duplicate :  
JDK-4655198 - RFE: java.lang.Boolean should implement java.lang.Comparable
Description

Name: stC104175			Date: 04/12/2000


(see also 4214818)

java version "1.2"
Classic VM (build JDK-1.2-V, native threads)

Boolean doesn't implement the Comparable interface.

This means that we can't put it into a JTable and assume that objects in the
model will be sorted according their comparable interface.

Replace table by any type of collection object and you see this is a serious
drawback.

We have to check if the object is boolean or not instead of using comparable interface.

I can't understand the reason.

One could be that establish a natural order for Boolean objects could sound
ridiculous, but i can suggest one, true first, false second. Or another
convention, true second, false first. Any possibilities???.


Lets imagine a JTable with checkbox, integers, text and you want to see first
the items that are checked, but like boolean objects doesn't implement
comparable, the user can't group them.

Of course you can redesign the JTable Model and instead of cast objects to
comparable, you can start to use a beatiful collection of if and instanceof, but
we are talking about OOP, aren't we?

Call it bug, design problem or omission, but sure it is a problem
(Review ID: 102386) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
14-06-2004
EVALUATION I'm passing this bug on to the collections folk - it seems a reasonable request to us in GUI land. philip.milne@eng 2000-06-28 The current design is consistent with the language itself: it is a compile-time error to attempt to compare two booleans for order: if (true < false) // ERROR: WON'T COMPILE foo(); The wrapper class (Boolean) merely mirrors the behavior of the wrapped primitive. All wrapper classes behave this way (with the exception of float and double, whose "primitive ordering" does not fulfill the contract for Comparable.compareTo (due to the presence of NaN and -0). We would be willing to sacrifice this "design purity" on the altar of pragmatism, but I'm not convinced that there is a real need for comparing Booleans. It is extraordinarily rare to want to sort a list of Booleans. More common is to want to sort a list of objects containing a Boolean field based on this field, but doing this requires the use of a Comparator. If you're writing a Comparator anyway, it's straightforward to sort based on the Boolean field even though Boolean does not, itself, implement Comparable. joshua.bloch@Eng 2000-07-13 Over the years it has become apparent that it would make life easier for people if we provided this functionality. ###@###.### 2003-01-29
13-07-2000