Hashtable with initial values

[Markos Charatzas]

Hello there,

Is there a way to create a Hashtable with some initial values?

in a same way as an array?
E.g.
String[] strings = {"2", "2","2"};

Thanx

 

[Barry White]

As far as I know... no! It would be nice though.

 

[Joona I Palaste]

Hello there,

Is there a way to create a Hashtable with some initial values?

in a same way as an array?
E.g.
String[] strings = {"2", "2","2"};

Thanx

As far as I know... no! It would be nice though.

Make your own!

public class BarryWhiteHashMap extends java.util.HashMap
{
public BarryWhiteHashMap() {
super();
}
public BarryWhiteHashMap(Object[] keys, Object[] values) {
super();
for (int i=0; i<Math.min(keys.length, values.length); i++) {
put(keys, values);
}
}
}

 

[Suresh]

Hello there,

Is there a way to create a Hashtable with some initial values?

in a same way as an array?
E.g.
String[] strings = {"2", "2","2"};

Thanx

Create a Hashtable object and fill it with initial values, and then store
the object in a file (Serialization).

Next time just load the hashtable from the file.

 

[Chris Smith]

Is there a way to create a Hashtable with some initial values?

in a same way as an array?
E.g.
String[] strings = {"2", "2","2"};

You can't do it in the initializer at declaration, no. However, if the
Hashtable is a static field, you can say:

private static Hashtable ht = new Hashtable();
static
{
ht.put("a", "b");
...
}

If it's a field, the technique is similar:

private Hashtable ht = new Hashtable();
{
ht.put("a", "b");
...
}

And if it's a local variable, you can just put the values in with normal
code:

Hashtable ht = new Hashtable();
ht.put("a", "b");
...

HTH,

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

Hello there,

Is there a way to create a Hashtable with some initial values?

in a same way as an array?
E.g.
String[] strings = {"2", "2","2"};

Thanx

I have been dealing with really shitty code lately, so I thought I'd comment
on some of the code that I have seen posted on this thread, in the false
hope that it will make my job easier.

Hashtable ht = new Hashtable(); // eek!!
Map m = new Hashtable(); // much nicer

// choke, choke, spew, spew !
class X extends Hashtable
{

}

// *at least* use a Decorator
class X implements Map
{
private Map m = new Hashtable();
}

Why are you using Hashtable anyway ? Supporting < 1.2 VMs ?
Do you require thread safety ? Why haven't you chosen to use a HashMap ?
</two-cents-worth>

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
Home : +61 7 5502 7987
Work : +61 7 5552 4076
Mobile : 0408 711 099
(2003 VTR1000F)

 

[Chris Smith]

I have been dealing with really shitty code lately, so I thought I'd comment
on some of the code that I have seen posted on this thread, in the false
hope that it will make my job easier.

Hashtable ht = new Hashtable(); // eek!!
Map m = new Hashtable(); // much nicer

Nicer if the code is running on a post-1.2 JRE. However, if the code is
running on such a JRE, I'd much rather see:

Map m = new HashMap();

and then, if the braindead kind of auto-synchronization in Hashtable is
really a requirement:

m = Collections.synchronizedMap(m);

Seems to me that using an old class like Hashtable is a particularly
poor way of communicating the synchronization requirement... especially
when there's so much old code around that uses Hashtable just because
it's what was there.

On the other hand, there's good reason to avoid either HashMap or the
Map interface if you're shooting for 1.1 compatibility.

// choke, choke, spew, spew !
class X extends Hashtable
{

}

I agree. There are few good reasons to ever do this.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

I agree. There are few good reasons to ever do this.

I would be much stronger on that saying that there are very many very good
reasons to NOT do this. java.util.Properties is one such victim of this.
Like to use a LinkedHashMap or a TreeMap to keep your properties in a nice
order? Sorry you're out of luck because instead of having Properties wrap
the collection it is a subclass of Hashtable so can only ever use a
Hashtable.

Subclassing a collections object within an application is usually the wrong
way to go (unless you are actually making a new collections class).