abstract method in indirect superclass

[Dan Smith]

Hi.  These sort of questions are very useful, so keep them coming.  I've been on vacation, so am just now taking a look at this.

I immediately thought of this bug:
http://bugs.sun.com/view_bug.do?bug_id=8010681

> OTOH, in my intuitive understanding of JLS7 the following sentence
> would apply:
> 
> "Any of C's superclasses has an abstract method and C neither declares
> nor inherits a method that implements (§8.4.8.1) it."
> 
> Interpreting this sentence *in the context of C*, I see a method
> foo(T3) with no legal implementation.

Our problem here is the definition of "implements".  Your interpretation is that it should be tested by comparing signatures in the context of C.  JLS 7 is vague on this (it is also vague on just how we define a "method"), but I think the most stable interpretation is that, generally, we're talking about the declaration-site signature of the method.  In the special case of an inherited method that is "said to override" some additional methods, per 8.4.8.4, we're talking about the signature at the point that this overriding occurs.  (In other words, the overriding relation is monotonic with respect to inheritance: you can add new overrides via inheritance, but can't "undo" existing ones.)

The "In the context of C" interpretation doesn't work at all if we're talking about methods that are package-access, and thus not accessible to C.

The behavior of javac 7 and ecj 3.8 supports this latter interpretation.  That's not to say that we must definitively match what they do, but it does suggest that this approach is what was intended.

In the 0.6.2 spec, we clarify the error condition by (mostly) making the check a test for abstract methods that are members of the class, with a special rule for package-access methods.  This transformation relies on an assumption that "Any of C's superclasses has an abstract method and C neither declare nor inherits a method that implements (§8.4.8.1) it" iff either 1) the abstract method is a member of C; or 2) the abstract method is package-access and not overridden in C or any of its superclasses.

> By this comment, are you saying that the new interpretation has
> always been intended and the above example should be accepted for all
> versions of Java? Maybe this specific situation deserves a mentioning
> in this paragraph of discussion?


Yes.  I can add a discussion point.

—Dan