Why is java.util.Observable not an abstract class?
Solution 1:
Quite simply it's a mistake that Observable is a class at all, abstract or otherwise.
Observable
should have been an interface and the JDK should have provided a convenient implementation (much like List
is an interface and ArrayList
is an implementation)
There are quite a few "mistakes" in java, including:
- java.util.Stack is a class, not an interface (like Observable, bad choice)
- java.util.Properties extends java.util.Hashtable (rather than uses one)
- The java.util.Date class is a bit of a mess, and is not immutable!
- The java.util.Calendar class is a real mess
- No unsigned 'byte' type (this is a real pain and the source of many low-level bugs)
- java.sql.SQLException is a checked exception
- Arrays don't use
Arrays.toString(array)
as their defaulttoString()
(how many SO questions has this caused?) -
Cloneable
shouldn't be a marker interface; it should have theclone()
method andObject.clone()
should not exist
While on the soapbox, in terms of the language itself, IMHO:
-
==
should execute the.equals()
method (this causes loads of headaches) - identity comparison
==
should either be===
like javascript or a dedicated method likeboolean isIdentical(Object o)
, because you hardly ever need it! -
<
should executecompareTo(Object o) < 0
forComparable
objects (and similarly for>
,<=
,>=
)
Solution 2:
As a first approach, one could think that this is done to allow the user to use composition instead of inheritance, which is very convenient if your class already inherits from another class, and you cannot inherit from Observable class also.
But if we look to the source code of Observable, we see that there is an internal flag
private boolean changed = false;
That is checked everytime the notifyObservers is invoked:
public void notifyObservers(Object arg) {
Object[] arrLocal;
synchronized (this) {
if (!changed) return;
arrLocal = obs.toArray();
clearChanged();
}
for (int i = arrLocal.length-1; i>=0; i--)
((Observer)arrLocal[i]).update(this, arg);
}
But from a class composed by this Observable, we cannot change this flag, since it is private, and the methods provided to change it are protected.
This means that the user is forced to subclass the Observable class, and I would say that the lack of the "abstract" keyword is just a "mistake".
I would say that this class is a complete screwup.