Compile error on inheritance of generic inner class extending with bounds

9
votes

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.

2
javagenericsinheritanceinner-classes
Any chance you could try it with Java 6? It might be a compiler bug. – Michael Myers
Just tried it with Java 6. Same error message. Interesting... – Eyal Schneider
@mmyers: good idea @Eval: thanks, also tried myself on the mac 1.6 jdk - same error – Arne Burmeister

2 Answers

8
votes

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.

1
votes

Maybe this is not much progress, but I managed to reduce the above code to the following code that still exhibits the same weird behavior:

class Base<E> { 
    protected class BaseInner<I extends E>{
    } 
} 

class Sub<E> extends Base<E>{ 
    class SubInner extends BaseInner<E> { 
    }
}