HashMap with unspecified value type

[kleelof]

Hello,

Can I use a HashMap, or other Map Object, to store values of mixed types? Making the following possible:

HashMap.put("one", 1);
HashMap.put("two", "too");

take care,
lee

[PhHein]

Yes, you can.

[kleelof]

Ok,

So should I ask how? or is it some great secret?

If I declare my HashMap like this:

HashMap HM = new HashMap();

I get Eclipse talking about type safety, but, of course, it does allow me to keep using it.

HM.put("one", "one");
HM.put("two", 2);

HM.get("one");

This last line produces an error about trying to retrieve a non-object.

take care,
lee

[masijade]

That is a warning. If you don't want to see that then try using

HashMap<String, Object> HM = new HashMap<String, Object>();

since your keys all seem to be Strings, and the value must be at least an Object, anyway. (Although that kind of defeats the purpose of Generics.)

[kleelof]

Hello,

Thanks. Now, of course, that I see Object there, I wonder why I didn't think of that.

take care,
lee

[kleelof]

Hello,

Ok. I tried that. But it is causing another problem. Here is some sample code:

HashMap<String, Object>        hm  = new HashMap<String, Object>;

hm.put("one", 1);
hm.put("two", "too");
testFunction(hm.get("one"));

void    testFunction(int value)
{
}

This throws an error that testFunction is expecting an Integer, not an object. So, how do I get it to accept the '1' as an integer, not an object? Maybe I am using the wrong class. Maybe HashMap is not the best thing for the job.

take care,
lee

[masijade]

By casting the retreived Object to Integer, of course. (Integer) hm.get("one")

[j2me64]

Maybe HashMap is not the best thing for the job.

depending what you are looking for the HashMap is ok, but in order to use it you have to know "the whole story". if you want in order to retrieve your elements from a hashMap you have to overwrite the equals() and the hashCode() methods. if you don't, your code will compile but you won't find your elements. think about it: if your map contains objects with multiple member variables then which member should be used for searching? right, the one you override in the equals method. here is a small example i used for a dog object

public class Dog {
	public String name;
	public int age;

	public Dog(String n, int a) {
		name = n;
		age= a;
	}

	public boolean equals(Object o) {
		if ((o instanceof Dog) && (((Dog) o).name == name)) {
			return true;
		} else {
			return false;
		}
	}

	public int hashCode() {
		return name.length();
	}
}

so now when you search an object the hashMap can use your overridden method equals to find the object. the get your element you can call the get() method with an object reference in it or a string literal that contains the key.

[RamyaSivakanth]

Hi,
send the code completley.Which version u are using?.It should not throw error for you.
Just convert like this and store.
hm.put("one", new Integer(1));

[masijade]

Completely unrelated (j2me64) and completely wrong (ramya -- actually read the thread).

[kleelof]

Hello,

Thankyou everyone for your input.

I'm used to higher-level languages like ActionScript and VB. As I'm sure many of you may know, these languages can often handle typing a little less strictly.

But it is good to get the experience with a lower-level language like JAVA. It makes me appreciate the benefits of other languages and has helped me understand them better.

take care,
lee

[RamyaSivakanth]

Masijade,
Let us get the code piece from the user and come to conclusion.

[j2me64]

if you implement hashMaps with objects you lose the type safety of java, as long you don't check this in your methods. whatever, here is some code that runs with object

import java.util.HashMap;

public class TestClass {
	static HashMap<Object, Object> hm;

	public static void getObject(Object o) {
		System.out.println(hm.get(o));
	}

	public static void main(String[] args) {
		hm = new HashMap<Object, Object>();

		hm.put("one", (Integer) 1);
		getObject("one");
		hm.put("two", "2");
		getObject("two");
		hm.put(3, "three");
		// this way
		getObject(3);
		// or this way
		Integer three = new Integer(3);
		getObject(three);

	}
}

but i would never use such code without knowing which objects are passed to getObject()

[masijade]

Masijade,
Let us get the code piece from the user and come to conclusion.

No, because the last problem had to do with retreiving the integers from the hashmap, the adding (with autoboxing) worked just fine. So, no reason to wait on that code. Using "Object" as the generitised value meant he needed to cast it to Integer on retreival in order for the autoboxing to work to make an int out of it.

[masijade]

if you implement hashMaps with objects you lose the type safety of java, as long you don't check this in your methods. whatever, here is some code that runs with object

import java.util.HashMap;

public class TestClass {
	static HashMap<Object, Object> hm;

	public static void getObject(Object o) {
		System.out.println(hm.get(o));
	}

	public static void main(String[] args) {
		hm = new HashMap<Object, Object>();

		hm.put("one", (Integer) 1);
		getObject("one");
		hm.put("two", "2");
		getObject("two");
		hm.put(3, "three");
		// this way
		getObject(3);
		// or this way
		Integer three = new Integer(3);
		getObject(three);

	}
}

but i would never use such code without knowing which objects are passed to getObject()

No, really? (That's sarcams BTW). I mentioned in the post where I suggested "Object" myself, that it defeats the purpose behind Generics, but when you're adding just any old object to a HashMap, then there is not anything else you can really do, other than adding the SuppressWarnings annotation (which I find worse than using Object) to get rid of the "cast" and "raw" warnings related to the HashMap.

Please, people, nothing against trying to help, but please, at least make the advice relevant, and, preferably, not redundant.

[PhHein]

but please, at least make the advice relevant, and, preferably, not redundant.

Heh, fighting windmills again?

[masijade]

Yeah, I know, but sometimes I just can't help myself. ;-)