Extending parameter type in constructor declaration?

Question

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

Answer 1

I'm not sure about the multiple-inheritance argument:
there are a number of places where the inferencer is
working with an empty set of potential classes. For
example <? extends String>: String being final can't
possibly have a derived class.
Given <N extends Number & T>, I would expect due to
the type erasure rules that the type N would be erased
to Number for actual class file generation.Granted, but then the problem is the compiler doesn't know what T is here. If T turned out to be (pick any class) "Thread" then you've written N extends Number & Thread, which clearly doesn't work.
Whether this is the actual problem in this case or not I don't know, but I don't see to allow you to write 'N extends X & Y' unless the compiler could know at least one of X and Y is an interface. Given you have no bounds on T in your example this is impossible.
ComparableComparator
I've seen it in a number of libraries in addition to
JGA and no one has a better name for it. It is an
attempt to have one visible method of comparing
objects instead of two.Oh, I see, you're trying to do pattern matching:
class ComparableComparator<U extends Comparable<U>> implements Comparator<U> {
    public int compare(U x, U y) {
        return x.compareTo(y);
class Less<T> {
    public Less(Comparator<T> comp) {
    public Less() {
        this(new ComparableComparator<T>());
BoundToWork.java [33:1] type parameter T is not within its bound
        this(new ComparableComparator<T>());
                                      ^
1 error
Errors compiling BoundToWork.This won't compile because T is not bound so the compiler can't know T implements Comparable<T>.
One could write:
class Less<T extends Comparable<T>> {
    public Less(Comparator<T> comp) {
    public Less() {
        this(new ComparableComparator<T>());
}Which compiles but defeats the whole object of what you're trying to do...
The thing is, I don't understand how you're planning to use this, do you have in mind something like this?
    class NotComp {} //doesn't implement Comparable<NotComp >
    Less<NotComp > l1 = new Less<NotComp>(new NotCompComparator());
    class Comp implements Comparable<Comp> { ...}
    Less<Comp> l2 = new Less<Comp>();Are you essentially trying to say that the no-arg constructor should only be available if the type of the parameter T happens to extend Comparable<T>, and conversely if T is not Comparable<T> then one must use the one-arg constructor of less and explicitly supply a Comparator object?
If I've understood you correctly then I can't see how this can work. You're basically trying to constrain which constructors are available based on the interfaces implemented by the type parameter (T) in Less<T>. But that can't work... both constructors must be callable for all instantiations of Less<T> ?
Please forgive me if I've gone off on a total tangent and misunderstood your intent.