Better way to use Hashtables? Java

Question

I have a class named Stored that will hold my Hashtable, which will hold Objects from the Class "Item". I have never used Hashtables before or really know all that much about them, but from my snooping around it seems as if there is a lot of different ways to use them. So my question is, which is the best? And why?

CODE UPDATED

I have in my program this...

public class Store implements Serializable{

Hashtable<String, Item> store = new Hashtable<String, Item>();

}

I have also seen this...

Hashtable<Object> store = new Hashtable<Object>();

Is one better than the other?

Also for reference my Item Class Objects will have 2 strings and an int as variables if that matters at all.

I'm also wondering if these Hashtables should need any constructor or maybe a size initialization? I have seen that in some examples and not in others. As far as I know they increase in size automatically so...whats the point?

EDIT:

I have this in my main...

Store store = new Store();

    Item item1 = new Item();
    item1.setProductName("Paper Towel Roll");
    item1.setBarCode("111222333444");
    item1.setQuantity(1);

    store.put("111222333444", item1);

    Item item2 = new Item();
    item2.setProductName("Paper Towel Roll");
    item2.setBarCode("111222333444");
    item2.setQuantity(1);

    store.put("111222333444", item2);

    Item item3 = new Item();
    item3.setProductName("Paper Towel Roll");
    item3.setBarCode("111222333444");
    item3.setQuantity(1);

    store.put("111222333444", item3);

    Item item4 = new Item();
    item4.setProductName("Paper Towel Roll");
    item4.setBarCode("111222333444");
    item4.setQuantity(1);

    store.put("111222333444", item4);

My put() calls don't work. Why can't I access my HashTable?

Answer 1

What you see is not related to Hashtables. It is a feature of the language called Generics. It allows you to restrict the type to use with the object you define, without having to créate a new Class.

A typical usage would be

 Hashtable<Integer, Item> store = new Hashtable<Integer, Item>();

That ensures that, in operations that use the type defined by you, only it is accepted if the type matches.

So,

 store.put(1, new Ítem());

would work, but

 store.put(2, new String("Hello world"));

would fail because String is not a subclass of Item.

If you do not use generics, v.g. old style Java

 Hashtable store = new Hashtable();

it would work, but the compiler won't detect any failure with

 store.put(2, new String("Hello world"));

so you lose (usually) useful controls.

Answer 2

If you want to use generics you can do it like this:

Hashtable<Key,Item> store = new Hashtable<Key, Item>();

If you go for a wrapper class around a Hashtable without the use of generics , you will have to do the casting from Object to Item yourself. I see no reason why you would do that.

Answer 3

Regarding size in initialization:
It is true that Collections (Hashtable as well) increase dynamically as you add items to them.
Initial capacity is the number of items that will be allocated in memory. If you don't give this number, initial capacity gets some default value (11 I think). As the Hashtable increases, a larger storage will need to be allocated. Reallocation requires some CPU work and can slow down the program in execution. So, by using the initial capacity number correctly, you can spare yourself some unnecessary CPU cycles, but on today's computers, unless you are doing some really really large insertions, I don't think it really matters.

Answer 4

The second example uses Generics which allows you to check type safety at a compile time and reduces the need for casts and is generally considered a better option. As for Hashtable constructors, for most cases you can use the no arg constructor which creates a Hashmap with default load factor 0.75 and innitial capacity 11. Load factor specifies when all elements of the hashtable will be copied to a bigger array. It happens when the number of elements exceeds load factor * capacity (internal array size). Other constructors allow you to specify load factor and innitial capacity. There are also a constructor to build a hashtable from existing Map. You should consider using HashMap instead of Hashtable in non-threaded applications for better performance. Also, from this line of code:

Hashtable<Object> store = new Hashtable<Object>();

I think you intended to use HashSet, because you store only values, not key - value pairs.

Answer 5

You want to use generics:

public class Store implements Serializable{
  Hashtable<Key, Item> store = new Hashtable<Key,Item>();
}

This ensures that only Item objects (and properly subclasses objects) can be placed in your Hashtable, which means you have to do less checking in any place where you use this hashtable.

Key can be anything you're using to reference your item; it might be Integer instead, or a String or some other object.

This prevents the following from happening:

public class Item {
  public String blah;
  ...
  public void printThisString() {
    System.out.println(blah);
  }
  ...
}

...

Hashtable store = new Hashtable();
Item item = new Item();
item.blah = "Hello world!";
store.put("FirstKey",item);
store.put("SecondKey","Hello world!");
...
store.get("FirstKey").printThisString();//Works fine!
store.get("SecondKey").printThisString();//Fails because String does not have a printThisString method.

This forces someone inserting into the hashtable to think about what they're doing:

Hashtable<String, Item> store = new Hashtable<String,Item>();
Item item = new Item();
item.blah = "Hello world!";
store.put("MyKey",item);
store.put("SecondKey","Three tears for all the souls!");//Will not compile because a String isn't an Item
...
store.get("MyKey").printThisString();//We can therefore be sure what is returned is an Item

CODE UPDATE

To address your code update:

Store<String, Item> store = new Store<String, Item>();

Item item1 = new Item();
item1.setProductName("Paper Towel Roll");
item1.setBarCode("111222333444");
item1.setQuantity(1);

store.put("111222333444", item1);//note that since it's quoted the key is a String