Summary

A code that names an inner class is erroneously classified as raw and as a result is erroneously rejected.

Problem

In the example that follows, javac determines erroneously that getter has a raw type (G.Getter). The type of getter is deduced as the raw type Getters<T>.Getter which is clearly not, since T, the type parameter of Getters<T> is not omitted. javac thinks that G is raw and raises the Object cannot be converted to T message in the following example. In this example Getter is simply an inherited member from the supertype Getters<T>:

static abstract class Getters<T> {
    abstract class Getter {
        abstract T get();
    }
}

static class Usage<T, G extends Getters<T>> {
    public T test(G.Getter getter) {
        return getter.get();       // incompatible types: Object cannot be converted to T
    }
}

Not looking into the bounds of G is a compiler bug.

A symmetrical situation occurs when there is a type application either explicitly or implicitly qualified and the enclosing type is not fully recalculated, for example the compiler crashes in the following two snippets.

class A<T> {
  protected class B<V> {}

  public static <T, M extends A<T>> void f(Object g) {
    @SuppressWarnings("unchecked")
    M.B<?> mapping = (M.B<?>) g;   // explicitly qualified type application
  }
}

class A<T> {
    class B<W> {
        public T rett() { return null; }
    }
}

class C extends A<String> {
    static class D {
        {
            B<?> b = null;         // implicitly qualified type application
            String s = b.rett();
        }
    }
}

The last examples are related to JDK-8357472.

Solution

javac has the necessary functionality to normalize qualified type paths. Taken from the comment in Attr:

// class Tree<A> { class Visitor { ... } }
// class PointTree extends Tree<Point> { ... }
// ...PointTree.Visitor...
//
// Then the type of the last expression above is
// Tree<Point>.Visitor.

The compiler performs the necessary traversal while calculating the qualifying type path of PointTree.Visitor with the type Tree<Point>.Visitor. In that case PointTree is a concrete class. The solution fixes the cases where the prefix of the path is not only a concrete class but a type parameter with a bound. In our case the correct type is: Getters<T>.Getter. The corresponding issue appears in the visitor method for parameterized types, in Attr, as well.

Specification

We believe there are no changes needed in the specification but you can find linked the JDK-8030746; a currently open spec bug around the same area -- 4.10: Define subtyping for inner classes of parameterized types.