Re: Casting an object to a genericized TreeMap

From:

"Kaiser S." <sausey@name.invalid>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 04 May 2007 10:04:41 +0200

Message-ID:

<463ae90b$0$5080$ba4acef3@news.orange.fr>

Daniel Pitts a ?crit :

On May 3, 6:41 am, "Kaiser S." <sau...@name.invalid> wrote:

Ingo R. Homann a ?crit :

Hi,
Kaiser S. wrote:

What do you think of this code ? Is there a better way do enforce this
kind of cast ?
    public static <K, V> TreeMap<K, V> treemap(Object o, Class<K>
keyClass, Class<V> valueClass) {
        TreeMap<?, ?> tm = (TreeMap)o; // warning 1
               for (Map.Entry<?, ?> couple : tm.entrySet()) {
            keyClass.cast(couple.getKey());
            valueClass.cast(couple.getValue());
        }
        return (TreeMap)o; // warning 2
    }
called with:
TreeMap<String, Double> tm = treemap(o, String.class, Double.class);

You know that your code does not do anything, and that the following
would do exactly the same?
public static <K, V> TreeMap<K, V> treemap(Object o) {
return (TreeMap<K,V>)o; // warning
}

Well i hope not. I check the class of all the keys and values; you must
have seen it...

Now the doc of Class.cast says it throw a ClassCastException if the cast
is invalid, so after the for loop, i can make the ugly cast because i'm
sure i won't get a ClassCastException somewhere else in my program.

If you really want to check the types, I suggest using instanceof
I'm kind of curious why you go through the effort. Whats going on that
you have a TreeMap object thats not in a TreeMap type reference?

I don't see how i can use instanceof in a general way. Trying to rewrite
the method with instanceof doesn't seem possible.

The object reference is because of a design flaw. We use a
treemap<string, object> as a generic class/object, which can contains
treemap:

public void doStuff(TreeMap<String, Object> myGenericObject) {
// instead of map1 = myGenericObject.getMap1();
TreeMap<Integer, Double> map1 = treemap(myGenericObject.get("map1"),
Integer.class, Double.class);
}

We have a lot of classes which overload the doStuff(...) method, and
each one has its own properties. That's the rationale behind the design
flaw.