Question

I have a problem when compiling a generic class with an inner class. The class extends a generic class, the inner class also.

Here the interface implemented:

public interface IndexIterator<Element>
    extends Iterator<Element>
{
  ...
}

The generic super class:

public abstract class CompoundCollection<Element, Part extends Collection<Element>>
    implements Collection<Element>
{
  ...

  protected class CompoundIterator<Iter extends Iterator<Element>>
      implements Iterator<Element>
  {
    ...
  }
}

The generic subclass with the compiler error:

public class CompoundList<Element>
    extends CompoundCollection<Element, List<Element>>
    implements List<Element>
{
  ...

  private class CompoundIndexIterator
      extends CompoundIterator<IndexIterator<Element>>
      implements IndexIterator<Element>
  {
    ...
  }
}

The error is:

type parameter diergo.collect.IndexIterator<Element> is not within its bound
       extends CompoundIterator<IndexIterator<Element>>
                                             ^

What is wrong? The code compiles with eclipse, but not with java 5 compiler (I use ant with java 5 on a mac and eclipse 3.5). No, I cannot convert it to a static inner class.

Answer 1

The Java Language Specification, §8.1.3, defines the semantics of subclassing inner types as follows:

Furthermore, for every superclass S of
C which is itself a direct inner class
of a class SO, there is an instance of
SO associated with i, known as the
immediately enclosing instance of i
with respect to S. The immediately
enclosing instance of an object with
respect to its class’ direct
superclass, if any, is determined when
the superclass constructor is invoked
via an explicit constructor invocation
statement.

Note that the enclosing instance is only described to be of a particular class, not a particular type. As all instances of a generic type share the same class, the following code would be legal:

class Base<E> {
    E e;

    protected class BaseInner<I extends E>{
        E e() { return e; }
    } 
} 

class StrangeSub extends Base<Integer> {
    protected class StrangeSubInner extends Base<String>.BaseInner<String> {}
}

Of course, this can be used to break the type invariant (i.e. cause heap pollution):

    StrangeSub ss = new StrangeSub();
    ss.e = 42;
    String s = ss.new StrangeSubInner().e();

The eclipse compiler takes the Java Language Specification as face value, and accepts the above code without even emitting an “unchecked” warning. While arguably technically compliant with the JLS, this clearly violates its intent.

The Sun Java Compiler rejects the declaration of StrangeSubInner with:

Test.java:32: type parameter java.lang.String is not within its bound
        protected class StrangeSubInner extends Base<String>.BaseInner<String> {}
                                                                       ^

Apparently the compiler didn’t simply check the type parameter against inner’s super class’ type parameter bound like eclipse did. In this case, I believe this the right thing to do, as the declaration is clearly unsafe. However, the Sun compiler equally rejects the following declaration, even though it is provably type safe:

class StrangeSub extends Base<Integer> {
    protected class StrangeSubInner extends BaseInner<Integer> {}
}

My hunch is that verifying the consistency of this diamond-shaped type restrictions is beyond the capabilities of the Sun compiler, and such constructs are therefore summarily rejected instead.

To work around this limitation, I’d first try to get rid of the type parameter to CompoundIterator.