That is a very good question. I shall give you one opinion about it
Joshua Bloch, Effective Java™ second edition, Upper Saddle River: Addison-Wesley, the Java™ Series . . . from the Source (2008), page 86.
. . . an "is-a" relationship exists between the two classes.
. . .
There are a number of obvious violations of this principle in the Java platform libraries. For example, a stack is not a Vector, so Stack should not extend Vector. Similarly, a property list is not a hash table, so Properties should not extend Hashtable. In both cases, composition would have been preferable.
Patricia Samuel wrote:
Why do some classes in API extends HashTable?
There can't be many and if they do they're very old. This is because its a long time ago now that Hashtable was replaced by the HashMap as the preferred hash based Map.
Are you asking why classes still extend Hashtable and why they're not changed to extend HashMap instead? That's because once something is in the Java API it's almost impossible to change because that would potentially break existing code.
Patricia Samuel wrote:
Shall i consider the thing what Embla said? Is it the only reason that some API extends Hashtable?
Embla explained why some classes extend Hashtable instead of HashMap.
The answer to your question: because they have to reuse some features of Hashtable, and their authors favored inheritance over composition - a bad design decision in most cases, see Ritchie's post!
String value = props.getProperty(key);
String value = (String) props.get(key);
If you were to design the Properties class today, it actually might make good sense to let it extend HashMap<String, String>, letting the language handle the type safety. Or alternatively, as people have already suggested, you could use composition instead.
As Ms Tingeling indicates, once a bad decision is made in the Java APIs, it lasts forever. Sun won't make a change that will stop existing code from compiling.
Now, regarding making the bad decision in the first place: people often forget that the oldest classes in the Java API (and that includes Hashtable, Properties, Stack, Vector, String, System, Math, Runtime, and many others) were written by people brand new to Java! That's obvious in retrospect, but you have to think about it first. These people came from their experience working in other languages, with other ways of doing things, notably Smalltalk and Scheme and to a lesser extend C++ (which at the time was often used with a popular class library called NIHCL, the NIH Class Library, which had a single-rooted inheritance hierarchy...) Anyway, the best practices for Java -- and for object-oriented programming in general -- have evolved a lot since the early nineties. It's easy to look back and say "that was a dumb idea!", but at the time, it was common practice. "Design Patterns" was published the year after the first public alpha of Java appeared.