6908259: Covariance bug for multiple interface inheritence

[David M. Lloyd]

On 02/09/2010 04:10 AM, Maurizio Cimadamore wrote:
> David M. Lloyd wrote:
>> I've produced a patch for javac bug #6908259 which appears to fix the
>> issue, at first blush. Before engaging in more rigorous testing and
>> figuring out how to do this jtreg thing, can someone in the know have
>> a glance over this patch and see if it makes any sense?
>>
>> See http://bugs.sun.com/view_bug.do?bug_id=6908259 for a detailed
>> description of the problem.
>>
>> My attached patch tries to work around the issue by detecting when two
>> incompatible methods are both overridden, and if so, it does an extra
>> check to see if the overriding method is a valid covariation (?) of
>> both methods.
> We also have a patch that is currently applied to JDK 7:
>
> http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4a3b9801f7a0
>
> The fix looks a bit more complex than yours (it adds a new method in
> check that finds the common covariant overrider in the superclass
> hiererachy) - in fact there could be situations in which the last method
> in the hierarchy does NOT define the common overrider, as in one of the
> regression tests attached above:

Wow - I had no idea that was supposed to be legal.  Now that I read the JLS 
in detail, I see two sections of interest - the first being JLS 8.4.8.1:

[-cut-]
8.4.8.1 Overriding (by Instance Methods)
An instance method m1 declared in a class C overrides another instance 
method, m2, declared in class A iff all of the following are true:

    1. C is a subclass of A.
    2. The signature of m1 is a subsignature (§8.4.2) of the signature of m2.
    3. Either
           * m2 is public, protected or declared with default access in the 
same package as C, or
           * m1 overrides a method m3, m3 distinct from m1, m3 distinct 
from m2, such that m3 overrides m2.

Moreover, if m1 is not abstract, then m1 is said to implement any and all 
declarations of abstract methods that it overrides.
[-cut-]

However, later on in 8.4.8.4:

[-cut-]
     * If all the inherited methods are abstract, then the class is 
necessarily an abstract class and is considered to inherit all the abstract 
methods. A compile-time error occurs if, for any two such inherited 
methods, one of the methods is not return type substitutable for the other 
(The throws clauses do not cause errors in this case.)

There might be several paths by which the same method declaration might be 
inherited from an interface. This fact causes no difficulty and never, of 
itself, results in a compile-time error.
[-cut-]

Note that they say "any two such inherited methods".  I guess that's a JLS 
bug, because surely if there exists an overridden method which is 
compatible with all the inherited methods, it is not a compile time error?

</pretend-code-lawyer>

- DML