Table of Contents
1. License
See the LICENSE file for license rights and limitations (MIT).
2. Overview
Although Java generics are rather limited comparing to ‘true’ generics, it’s still possible to extract and use their data in some circumstances:
Here we are unable to extract type argument’s value (String) given, say, a reference to the data field:
class MyClass {
List data = new ArrayList<String>();
}
In contrast, here we can find out that target type argument’s value is Number:
class MyClass implements Comparable<Number> {
}
Current library helps with type argument values extraction and processing.
3. API
Extract type argument value
That functionality is covered by the TypeArgumentResolver interface.
Example
Given the declarations below:
class MyInterface<A, B> {}
class StringParent<T> implements MyInterface<String, T> {}
class Child extends StringParent<Long> {}
We can find out the following:
typeArgumentResolver.resolve(MyInterface.class, Child.class, 0) -> String
typeArgumentResolver.resolve(MyInterface.class, Child.class, 1) -> Long
Real-world usage example:
interface Handler<T> {
void handle(T input);
}
class StringHandler implements Handler<String> {
public void handle(String input) {}
}
class LongHandler implements Handler<Long> {
public void handle(Long input) {}
}
@Component
class Router {
private final Map<Type, Handler<?>> handlers;
@Autowired
public Router(Collection<Handler<?>> handlers) {
this.handlers = JenomeResolveUtil.byTypeValue(handlers);
}
public void process(Object data) {
Handler handler = handlers.get(data.getClass());
if (handler == null) {
throw new IllegalArgumentException(String.format(
"No handler is registered for payload of type %s. Known payload mappings: %s",
data.getClass().getSimpleName(), handlers
));
}
handler.handle(data);
}
}
Check if one type IS-A another type
This functionality is covered by the TypeComplianceMatcher.
Example
interface TestInterface<A, B, C> {}
class TestInterfaceImpl<A, B, C> implements TestInterface<A, B, C> {}
class SimpleBaseClass implements TestInterface<Integer, Long, String> {}
class SimpleMatchedClass extends TestInterfaceImpl<Integer, Long, String> {}
class SimpleUnmatchedClass extends TestInterfaceImpl<Integer, Long, Number> {}
typeComplianceMatcher.match(SimpleBaseClass.class.getGenericInterfaces()[0], SimpleMatchedClass.class.getGenericSuperclass()) -> true
typeComplianceMatcher.match(SimpleBaseClass.class.getGenericInterfaces()[0], SimpleUnmatchedClass.class.getGenericSuperclass()) -> false
This is a must-have functionality when we want to, say, enhance autowiring rules by type argument values. E.g. consider a spring context with beans of the following types:
MyClass<Integer>
MyClass<Long>
MyClass<String>
MyClass<StringBuilder>
We’d like to be able to autowire arguments like Collection<Number> (MyClass<Integer> and MyClass<Long> go here) and Collection<CharSequence> (MyClass<String> and MyClass<StringBuilder> should be provided).
Note: right now Spring checks only the base type (MyClass) and provides all such beans regarding the type argument’s value.