Generics function call not compiling in java 8 extending multiple interfaces

Question

Running Java 1.8 JavaSE-1.8 (jdk1.8.0_20)

This class:

public class SimpleQuestion {

    public static void main(String[] args) {
        DoNothing();
        DoNothing2();
        DoNothing3();
        DoNothing4();
    }    

    public interface Interface1 {
        public void go();
    }

    public interface Interface2<X> {
        public X go2();
    }

    private static <X, T extends Interface2<X> & Interface1> void DoNothing() {
        return;
    }

    private static <X, T extends Interface2 & Interface1> void DoNothing2() {
        return;
    }

    private static <X, T extends Interface2<X>> void DoNothing3() {
        return;
    }

    private static <T extends Interface2<T> & Interface1> void DoNothing4() {
        return;
    }    

}

gives the compile error:

The method DoNothing() in the type SimpleQuestion is not applicable for the arguments ()

Why that one and not DoNothing2,3, and 4?

Answer 1

The error message appears to be referring to a failure of the algorithm defined in section 18.5.1 of the spec.

For DoNothing, the algorithm proceeds as follows (using the terminology from the above link):

• The type parameters are

  P1 = X

  P2 = T extends Interface2<X> & Interface1

  and I'll use a1 and a2 for the corresponding inference variables.

• The initial bound set is

  B0 = {a1 <: Object, a2 <: Interface2<a1>, a2 <: Interface1}

• There are no arguments, so no extra bounds are added at this point (B2 = B0).

• There is a dependency of a2 on a1, so we try to resolve a1 first. It has a proper upper bound of Object, so we instantiate it to this. Incorporating a1 = Object involves adding the bound

  a2 <: Interface2<Object>

• Next we resolve a2. This now has two proper upper bounds, so we instantiate a2 to their glb:

  a2 = Interface2<Object> & Interface1

• Every variable now has an instantiation, so resolution has succeeded.

Hence, contrary to the error message, the invocation of DoNothing ought to be applicable. This appears to be a bug in your Java compiler.