I'm populating my hashtable with records from a database table where one of the fields is the hashtable key. The problem is, when i print those keys and their values out, they come out in a different order from that of the table. How do i preserve the order of the objects in Hashtable (i.e the objects should be in the same order as that of the table). Or is there any other class which preserves the order as well as maintaining a key-value pair
We solved the problem by created a custom class exteding the hashtable class. Here we maintain the order in a vector. It works great.
Joined: May 24, 2001
Hi Mike, Thanks for the tip. The TreeMap really works. But again there is a hitch. The TreeMap class takes up too much of memory(it allocates abt 101 hashtable entries) which is just too much for my appl. Is there any way that i can specify the initialy capacity as well as the incremetal capacity. Thanks, Arjun
Originally posted by Mike Curwen: Have you considered the TreeMap or TreeSet (java.util)
Doesn't a TreeMap hold objects in their 'natural order'? This wouldn't necessarily mean they'll be held in the same order as they were on the table, unless they're already held in numeric or alphabetic order there.
Paul, Could you please explain on what you mean by 'natural order' in TreeMap. Also there is no constructor in TreeMap by which i can specifiy the capacity and/or the load factor. Finally I ended up creating a custom class extending Hashtable with a Vector object in it to store the order in which objects are added to Hashtable.
Natural order for a class is defined by implementing the Comparable interface. For example, for a String the compareTo() method is defined to reflect alphabetic ordering. It doen't sound like this is what you want though - you want the order in which the elements were added in the first place, which will have nothing to do with the natural order. I don't think TreeMap is any use to you for this. As David previously noted, there is no use for having any unused nodes on a TreeMap, and therefore no extra capacity or load factor to deal with. A TreeMap is always exactly as big as it needs to be, no bigger.
[This message has been edited by Jim Yingst (edited August 06, 2001).]