Java Generics, the type gets lost

user_4486863 0
Viewed 236

The following example, although seemingly correct, won't compile (Eclipse Neon 3, Java 1.8):

class Test {    

    public static class SomeForm<IF extends SomeForm<IF>> {

    }

    public static class BaseFF<IF extends SomeForm<IF>> {

    }

    public static class AuxFF<IF extends SomeForm<IF>>
            extends BaseFF<IF> {

    }

    public interface Interface<IF extends SomeForm<IF>, FF extends BaseFF<IF>> {
        FF getFF1();        
    }

    public static class ZBaseUnit<IF extends SomeForm<IF>, FF extends BaseFF<IF>>
            implements Interface<IF, FF> {

        @Override
        public FF getFF1() {
            return null;
        }

    }

    public static class ZMyUnit<IF extends SomeForm<IF>, FF extends AuxFF<IF>>
            extends ZBaseUnit<IF, FF> {

    }

    public static class ZMyCheck<IF extends SomeForm<IF>, U extends ZMyUnit<IF, ?>> {
        U unit;

        void f() {
            BaseFF<IF> ff1 = unit.getFF1();
        }

    }

}

Eclipse says (on the line inside f() method):

"Type mismatch: cannot convert from capture#2-of ? to Test.BaseFF".

However, if I remove the method getFF1 from the interface Interface (and the @Override annotation in the class ZBaseUnit), it compiles. Is there some logic behind this? Intuitively, it seems that FF passed to Interface is the same as FF passed to ZBaseUnit, so there should be no difference...

Also, there is no error if I add the method in ZMyUnit:

void f() {
    BaseFF<IF> ff1 = getFF1();
}

Any help would be appreciated!

compiler-errors eclipse generics java
2 Answers

If you add this verification code to you class

public static class GF extends SomeForm<GF> {
}

public static void main(String[] args) {
    ZMyCheck<GF, ZMyUnit<GF, AuxFF<GF>>> z = new ZMyCheck<>();
    z.unit = new ZMyUnit<>();
    z.f();
    System.out.println("OK");
}

and use standard JDK command-line tools (javac and java), then the code will compile and run successfully. The same is true if you use NetBeans (I have no intention to promote NetBeans in any way).

Therefore, the problem is Eclipse-specific. Eclipse has its own built-in compiler and it seems that you've found one of its weaknesses (maybe you need to file a bug report). It is unable to determine that the wildcard ? is, in fact, referring to the type that extends AuxFF<IF> (and, therefore, BaseFF<IF>). You need to indicate this explicitly:

public static class ZMyCheck<IF extends SomeForm<IF>,
    U extends ZMyUnit<IF, ? extends AuxFF<IF>>> {...}

Then all will compile and run swimmingly.

user_97726910

With respect to class ZMyCheck and the variable initialization within ...

    public static class ZMyCheck<IF extends SomeForm<IF>, U extends ZMyUnit<IF, ?>> {
        U unit;

        void f() {
            BaseFF<IF> ff1 = unit.getFF1();
        }

    }

... the correctness ultimately comes down to the type of the expression unit.getFF1(), and whether that type is a subtype of BaseFF<IF>. The type of that expression is a function of the type of instance variable unit, which, as a result of type erasure, is interpreted as the upper bound of type variable U, that is, ZMyUnit<IF, ?>.

With respect to the type of unit.getFF1(), then, the JLS specifies that

The types of the fields, methods, and constructors [of a type] are the types of the fields, methods, and constructors in the capture conversion of [that type].

(JLS 10, 4.5.2)

We therefore need to determine the capture conversion of type ZMyUnit<IF, ?>, as specified in section 5.1.10. The specification gets fairly technical here, but the bottom line is that the upper bound of ZMyUnit's second type parameter factors in, so that there is a capture conversion to type ZMyUnit<IF, AuxFF<IF>>. Interpreted according to that type, method getFF1() returns type AuxFF<IF>, which is subject to a widening reference conversion to type BaseFF<IF>, and that is what is needed.

Thus, as @JohnMcClane also answered, Eclipse's compiler is incorrect in rejecting the code presented. Adding an appropriate upper bound to the wildcard seems to work around the issue without changing the semantics of the code with respect to the JLS.

user_24022720
Related