• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why some classes extends HashTable

 
Patricia Samuel
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Why do some classes in API extends HashTable?

Please clarify.

Regards
Patricia


 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's Hashtable, not HashTable.

That is a very good question. I shall give you one opinion about it
. . . 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.
Joshua Bloch, Effective Java™ second edition, Upper Saddle River: Addison-Wesley, the Java™ Series . . . from the Source (2008), page 86.
 
Embla Tingeling
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Mr. Campbell,

I m sorry but i can't get the explanation you mentioned.

Shall i consider the thing what Embla said? Is it the only reason that some API extends Hashtable?

Please reply.

Regards,
Patricia Samuel.

 
Lorand Komaromi
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!

 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think about the class "Properties". It is supposed to hold pairs of Strings. I have one String, the "key", and the Properties object can give me the other String, the "value". That sounds a lot like what Hashtable is supposed to do, except Hashtable does it with Objects. Someone decided -- and i think we can all agree, it was a bad decision -- to implement Properties by extending Hashtable and adding a few methods that cast Object to String, so you can say

String value = props.getProperty(key);

instead of

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.
 
Patricia Samuel
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Ernest ,

Thanks for giving time to this post. Its really a very very nice explanation for me.



Cheers,

Patricia.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic