I submitted the bug, but they've responded with "there is no chance that
we address this.": https://bugs.eclipse.org/bugs/show_bug.cgi?id=148660

   I guess I'll have to stick with Stefans fix.

   - Oliver

 My own knowledge about type parameters is very irregular:
 I only know about those parts that recently came along my
 way incidentally, but I am not an expert in this field.

 I was able to compile something similar to the above
 code after I removed »static« and moved the declaration
 of »T« to the enclosing class:

interface IOne { void methodOne(); }
interface ITwo { void methodTwo(); }

class A implements IOne, ITwo
{ public void methodOne(){} public void methodTwo(){} }

class B implements IOne, ITwo
{ public void methodOne(){} public void methodTwo(){} }

public class Main< T extends IOne & ITwo >
{
 private final java.util.Map<T, java.lang.Object> mapping =
 new java.util.HashMap<T, java.lang.Object>();

 private
 int myCode( final T myVar, int someParam )
 { myVar.methodOne();
   myVar.methodTwo();
   return someParam; }

 public static void main( final java.lang.String[] args )
 { new Main<A>().myCode( new A(), 0 );
   new Main<B>().myCode( new B(), 0 );
   java.lang.System.out.println( "2006-06-26T19:18:10+02:00" ); }}

 

If you were writing that for one interface, you would have:

    private static final Map<? extends Appendable,String> map =
        createMap();

    private static <T extends Appendable> Map<T,String> createMap() {
        return new java.util.HashMap<T,String>();
    }

(Implicit capture is a bit more flexible than what you can write
explicitly.)

I've been meaning to have a play with this for intersection types for
some time.

You can slide in a layer of indirection. It does require some copy &
paster work, but it be required too often. Here's some code I wrote a
minute ago:

final class AppendableCharSequenceRef<
    T extends Appendable & CharSequence

    // The basics...

    private final T value;

    public AppendableCharSequenceRef(T value) {
        this.value = value;
    }

    public T get() {
        return value;
    }

    // The trimmings...

    public void get(Handler<Appendable,CharSequence> handler) {
        handler.handle(value, value);
    }

    public <
        N extends Appendable & CharSequence
    > AppendableCharSequenceRef<?> ref(N value) {
        return
            this.value==value ?
            this :
            new AppendableCharSequenceRef<N>(value);
    }

    public static final AppendableCharSequenceRef<?> NULL =
newInstance(null);

    public static <
        N extends Appendable & CharSequence
    > AppendableCharSequenceRef<N> newInstance(
        N value
    ) {
        return new AppendableCharSequenceRef<N>(value);
    }

    public static <
        N extends Appendable & CharSequence
    > AppendableCharSequenceRef<?> of(
        N value
    ) {
        return NULL.ref(value);
    }
}

interface Handler<A,B> {
    void handle(A asA, B asB);
}

class Intersect {
    private AppendableCharSequenceRef<?> x;

    public Intersect() {
        this.x = AppendableCharSequenceRef.NULL;
    }

    public <T extends Appendable & CharSequence> Intersect(T x) {
        this.x = AppendableCharSequenceRef.of(x);
    }

    public <T extends Appendable & CharSequence> void set(T x) {
        this.x = this.x.ref(x);
    }

    public void set(AppendableCharSequenceRef<?> xRef) {
        if (xRef == null) {
            throw new NullPointerException();
        }
        this.x = xRef;
    }
    public AppendableCharSequenceRef<?> getAsRef() {
        return x;
    }
    public Appendable getAsAppendable() {
        return x.get();
    }
    public CharSequence getAsCharSequence() {
        return x.get();
    }

    public void get(Handler<Appendable,CharSequence> handler) {
        x.get(handler);
    }

    public void append(char c) throws java.io.IOException {
        x.get().append(c);
    }
    public char getAt(int off) {
        return x.get().charAt(off);
    }
}

Tom Hawtin

I don't see this as a problem.  By encapsulation, you should not worry
too much about the internal state of objects.  But if you insist on
worrying, you can specify the Constructors in OneAndTwo to ensure o and
t are the same object like this:

private OneAndTwo ( ) { throw ( new IllegalArgumentException ( ) ) ; }
// no no-argument constructor allowed
private OneAndTwo ( IOne o , ITwo t ) { o=o ; t=t ; }
public OneAndTwo ( A obj ) { this ( obj , obj ) ; } // o and t are the
same
public OneAndTwo ( B obj ) { this ( obj , obj ) ; } // B also
implements IOne,ITwo but not OneAndTwo