涉及 generics 的类型安全异构容器

Question

I need to create a container that provides a way for me to store elements of generic type, kind of like this effective java pattern but storing generic things

Is it possible to create a typesafe heterogeneous container where generic typed things are involved?

<T> void put(T ele, SomeTypedThing<T> genEle);
<T> SomeTypedThing<T> get(T ele);

I am fine to add the Class<T> as method param. example:

public static class Container {

    Map<Class<?>, Set<?>> store = new HashMap<>();

    public <T> void put(Set<T> ele, Class<T> type) {
        store.put(type, ele);
    }

    public <T> Set<T> get(Class<T> type) {
        return store.get(type);
    }
}

would it be possible to achieve this?

Set<?> raw = store.get(type);
Set<T> typed = // some magic;

how, or why not? is it something that java doesn't do or is it something fundamental (so no language can do, or just doesn't make sense to do)

Answer 1

The problem is with the wildcard parameter on the Set . Instead of using a Set<?> , make it a Set<Object> , and everything works:

public static class Container {

    Map<Class<?>, Set<Object>> store = new HashMap<>();

    public <T> void put(T ele, Class<T> type) {
        store.putIfAbsent(type, new HashSet<>());
        store.get(type).add(ele);
    }

}

The difference between Set<?> and Set<Object> is this:

A Set<?> could be a Set of any type - it could be a Set<String> or a Set<Integer> . And the java compiler wants to make sure that you are not trying to add a String object to a Set<Integer> .

On the other hand, a Set<Object> is just a Set that can contain instances of the Object class. And since String and Integer are both subclasses of Object , you can easily store strings and Integers into such a set.

Adding the method

    public <T> Set<T> get(Class<T> type) {
        return (Set<T>) store.get(type);
    }

to the class gives a compiler warning about an unchecked cast. This warning can be safely ignored here, because you know that you added only elements of type T to that Set .

Answer 2

Thomas Klägers solution is an answer that also came to my head. Creating an fully functioning heterogeneous container which works like this:

Set<?> raw = store.get(type);
Set<T> typed = // some magic;

But as far as I know, It is not possible to use container You mentioned with that 'smooth' code I quoted above. However it is usable and You can get sets of Your stored by class sets. Here goes the code:

public class Container {

    Map<Class<?>, Set<Object>> container = new HashMap<>();

    public <T> void put(T e, Class<?> type) {
        container.putIfAbsent(type, new HashSet<>());
        container.get(type).add(e);
    }

    public <T> Set<T> get(Class<T> type) {
        @SuppressWarnings("unchecked") //It is fine to ignore warnings here
        Set<T> res = (Set<T>) container.get(type);
        return res;
    }
}

And working example of storing ang retreiving Containers elements: public class Run {

public static void main(String[] args) {
    Foo foo = new Foo();
    Bar bar = new Bar();

    Container con = new Container();
    con.put(foo, foo.getClass());
    con.put(bar, bar.getClass());

    Set<? extends Foo> foos = con.get(foo.getClass());
    Set<? extends Bar> bars = con.get(bar.getClass());

    //here You can use Your sets as ususal
}

If approach <? extends Foo> <? extends Foo> and usage is fine for You, it's working solution. Above that if You work in Java 10+, there's possibility for that 'dirty' declaration omission. Just declare it as var and poof, its hidden.

Answer 3

I stumbled upon this problem a few weeks ago as I needed a typesafe heterogenous container (THC) for literally any object (including generic interface implementations) AND any number of them (like two keys that provide a String for example).

The previous two answers are "weak" THCs because they do not provide compile time type safety.

Although this question is rather old, I'd like to provide another approach.

The "why" it is not possible with a generic type is based on Java's type erasure . THCs are all about parameterizing the keys. So you can use a key object that wraps the class type instead of using the class type as key.

For example: Key-Class:

static class Type<T> {
    private final Class<T> object_type;

    public Type(String name, Class<T> object_type){
        this.object_type = object_type;
    }
    public Class<T> getObjectType() {
        return object_type;
    }
}

Container-Class:

static class Container{

    private final Map<Type<?>, Object> properties = new HashMap<>();

    public <T> T get(Type<T> type){
        return type.getObjectType().cast(properties.get(type)); //no compiler complaints
    }

    public <T> void put(Type<T> type, T value){
        properties.put(type, type.getObjectType().cast(value)); //no compielr complaints
    }
}

Since we can't provide Set<Foo>.class as object type we have like two possibilites. Either we use inheritence or we use composition.

Inheritence:

static class IntHashSet extends HashSet<Integer>{}

Composition:

static class IntSetComposition{

    private final Set<Integer> set;
    public IntSetComposition(Set<Integer> set){
        this.set=set;
    }
    public Set<Integer> getSet(){
        return this.set;
    }
}

How to use all this:

public static void main(String[] args) {
    Type<String> string_type = new Type<>("string_type_1", String.class);

    Type<Integer> int_type = new Type<>("int_type_1", Integer.class);

    Type<IntHashSet> int_set = new Type<>("int_hashset", IntHashSet.class);        
    Type<IntSetComposition> int_set_comp = new Type<>("int_set_comp", IntSetComposition.class);        

    Container container = new Container();

    String s = container.get(string_type); //no compiler complaints
    int i = container.get(int_type); //no compiler complaints

    IntHashSet set = container.get(int_set); //no compiler complaints
    Set<Integer> set2 = container.get(int_set_comp).getSet(); //no compiler complaints

    String s2 = container.get(int_type); //the compiler does not like this!
}