Java如何使用Set参数化通用方法？

Question

I have a method with such signature:

private <T> Map<String, byte[]> m(Map<String, T> data, Class<T> type)

When I invoke like this for example it is working fine:

Map<String, String> abc= null;
m(abc, String.class);

But when my parameter T is a Set it doesn't work:

Map<String, Set<String>> abc= null;
m(abc, Set.class);

Is there a way to make it work?

Answer 1

You're going to have to do something really ugly, using an unchecked cast like this:

m(abc, (Class<Set<String>>) (Class<?>) Set.class);

This comes down to type-erasure. At runtime Class<Set<String>> is the same as Class<Set<Integer>> , because we don't have reified generics, and so there is no way to know that what you have is a class for a "Set of strings" vs. a class for a "Set of integers".

I asked a related question some time ago that should also give you some pointers:

• Return a class instance with its generic type

IMO this confusion is due to the fact the generics were bolted on after the fact, and aren't reified. I think it's a failing of the language when the compiler tells you that the generic types don't match, but you don't have an easy way of even representing that particular type. For example, in your case you end up with the compile-time error:

        m(abc, Set.class);
        ^
  required: Map<String,T>,Class<T>
  found: Map<String,Set<String>>,Class<Set>
  reason: inferred type does not conform to equality constraint(s)
    inferred: Set
    equality constraints(s): Set,Set<String>
  where T is a type-variable:
    T extends Object declared in method <T>m(Map<String,T>,Class<T>)

Now it would be perfectly reasonable for you to think "Oh, I should use Set<String>.class then", but that is not legal. This is abstraction leakage from the implementation of generics in the language, specifically that they are subject to type-erasure. Semantically, Set<String>.class represents the runtime class instance of a set of strings. But actually at runtime we cannot represent the runtime class of a set of strings, because it is indistinguishable from a set that contains objects of any other type.

So we have a runtime semantic that is at odds with compile-time semantic, and knowing why Set<T>.class isn't legal requires knowing that generics are not reified at runtime. This mismatch is what leads to weird workarounds like these.

What compounds the problem is that class instances also ended up being conflated with type-tokens. Since you do not have access to the type of the generic parameter at runtime, the work around has been to pass in an argument of type Class<T> . On the surface this works great because you can pass in things like String.class (which is of type Class<String> ) and the compiler is happy. But this method breaks down in your case: what if T itself represents a type with its own generic-type parameter? Now using classes as type-tokens is not useful because there is no way to distinguish between Class<Set<String>> and Class<Set<Integer>> because fundamentally, they are both Set.class at runtime and so share the same class instance. So IMO, using a class as a runtime type-token doesn't work as a general solution.

Due to this shortcoming in the language, there are some libraries that make it very easy to retrieve the generic type-information. In addition they also provide classes are better at representing the "type" of something:

• TypeTools
• Reflection Explained: Google Guava

Answer 2

From what I see, there are two potential solutions to this problem in which both have their respective limitations.

The first solution relies on the fact that java's type erasure is complete , meaning that types for any parametrized types are erased regardless of "depth". For example: a Map<String, Set<String> will get reduced to Map<String, Set> and then Map<Object, Object> meaning that whilst type information is hard to obtain, it technically isn't needed during runtime given that any object can be inserted into the Map (given that it passes all class casts).

With this, we can create a relatively "ugly" (compared to the second solution) method of obtaining runtime type information through an instance present in the map. By doing so, regardless of how many sets you embed and what the resultant "type" is present after erasure, we can guarantee that an instance of it will be insertable back into the original map.

Demonstrated below:

// Java 7 approach
private <T> Map<String, byte[]> m(Map<String, T> data){
    Class valueType = null;

    Iterator<T> valueIterator = data.values().iterator();

    while(valueIterator.hasNext()){
        T nextCandidate = valueIterator.next();

        if(nextCandidate != null){
            valueType = nextCandidate.getClass();
            break;
        }
    }

    if(valueType == null){
        // No instance present, fail
        return null;
    }

    // Create a new instance
    T obj = (T) valueType.newInstance(); // Exception handling not shown

    // Rest of code here

    return null;
}

as seen, the type information is extracted directly from the first non-null value present within the map. Under java 8 we can do better using streams:

// Java 8 approach
private <T> Map<String, byte[]> m(Map<String, T> data){
    // Note: use findFirst() for more consistent behaviour
    Optional<T> optInstance = data.values().stream().filter(Objects::nonNull).findAny();

    if(!optInstance.isPresent()){
        // No instance present, fail
        return null;
    }

    Class valueType = optInstance.get().getClass();

    // Create a new instance
    T obj = (T) valueType.newInstance(); // Exception handling not shown

    // Rest of code here

    return null;
}

However, this solution has a couple of limitations. As stated, the map has to contain at least one non-null value for the operation to be successful. And secondly, this solution doesn't take account of subclassing of the declared type (? extends T) on specific elements which may provide to be problematic if you have elements of different classes (eg TreeSet and HashSet within the same map).

The second issue can be solved easily by dealing with type information on a key-value pair basis rather on a "whole" map basis though this comes at the cost of "knowing" the type information for all elements within the map. Alternatively, more complex solutions such as devising the most specific common superclass to all non-null values within the map can also be used, but for all intents and purposes, this becomes more of a guesstimate solution than a real one.

---

The second solution to this problem is, in my opinion, a lot cleaner but poses additional complexity to the caller. This approach follows a more functional approach and can be applied if there are only a limited number of type-dependent operations within the method. Following your proposed case of instantiation of the generic type T, we can modify the method as follows:

private <T> Map<String, byte[]> m(Map<String, T> data, Callable<T> creator){
    // Create a new instance
    T obj = creator.call(); // Exception handling not shown

    // Rest of code here

    return null;
}

and called as follows:

Map<String, Set<String>> data = new HashMap<>();

// Instantiation method set to new HashSet (thanks to bayou.io for HashSet::new)
m(data, HashSet::new); // Note: replace with anonymous inner class for java 7

in this case, the type information (which is present at the level of the caller) can be bypassed by having the caller provide the type-dependent functionality required. The example provides a basic HashSet creation for all values but more complex instantiation rules can be defined on a per-element basis.

The downside to this approach is that it provides complexity to the caller and can be very bad if this were to be an external API function (though the use of private within your original method suggests otherwise). Java 7 and below also causes quite a bit of boilerplate anonymous inner class code to pop up making caller-side code harder to read. Additionally, if most of your method requires type-information to be present then this solution is less feasible as well (since you'd be reprogramming most of your method on a per-type basis, defeating the point of using generics).

---

In all, I'd personally prefer to use the second approach if possible, only using the first approach if deemed infeasible. The gist of the solutions I'm getting at here is to not rely on type information when dealing with generics or at least set a bound such that you get functionality you require without ugly hacks. In the case where type-dependent operations have to be performed, have the caller provide the functionality for that (through Callables, Runnables or some FunctionalInterface of your creation).

If type information is absolutely critical for some reason not made apparent, I suggest reading this article to stop type erasure altogether, allowing type information to be present directly from within the method.

Answer 3

The following signature works with super keyword. (I tested with Java7)

private <T> Map<String, byte[]> m(Map<String, T> data, Class<? super T> type)

Map<String, Set<String>> abc = null;
m(abc, Set.class);

This is subtyping for generics.

Answer 4

You'd need to do it like :

Map<String, Set> abc = null;  //gives a compiler warning
m(abc, Set.class)

The issue is that if you want T to be captured to Set<String> , there will be no way to express Class<T> since there's no such thing as Set<String>.class , just Set.class .