Why is java.util.Observable not an abstract class?

Question

I just noticed that java.util.Observable is a concrete class. Since the purpose of Observable is to be extended, this seems rather odd to me. Is there a reason why it was implemented this way?

I found this article which says that

The observable is a concrete class, so the class deriving from it must be determined upfront, as Java allows only single inheritance.

But that doesn't really explain it to me. In fact, if Observable were abstract, the user would be forced to determine the class deriving from it.

Answer 1

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.

Answer 2

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 default toString() (how many SO questions has this caused?)
• Cloneable shouldn't be a marker interface; it should have the clone() method and Object.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 like boolean isIdentical(Object o), because you hardly ever need it!
• < should execute compareTo(Object o) < 0 for Comparable objects (and similarly for >, <=, >=)