I've come across a couple of places where I really want to have the compiler use a specific implementation for types of generic parms. As things stand now, I write two classes: one that defines a general mechanism, and one (may or may not be derived from the first) that provides a more specific mechanism.
I know that this isn't possible given the generic type erasure, but I thought I came up with a way to make it work. Of course, this doesn't work either, but I wanted to know what potential misuse causes this syntax to be rejected by the spec.
public class TNum<T> {
private T value;
public TNum(T value) { this.value = value; }
public <N extends Number & T> TNum(N value) { // compiler rejects this in either order
this(value);
}
}
So far, the two cases that I'd use this type of technique:
1) Comparison functors -- there are two choices generally
class Less<T> {
public Less(Comparator<T> comp) {...}
}
class Less<T extends Comparable) {
public Less() {}
}
I could eliminate a class if I could write
class Less<T>{
public <T> Less(Comparator<T> comp) { ... }
public <C extends Comparable & T>Less() {
this(new ComparableComparator<C>());
}
}
2) Swing Editors & Renderers: the basic implementation is the same for all parm types, but there are a couple of minor extensions when dealing with Numbers.
David Hall
http://jga.sf.net