6908259: Covariance bug for multiple interface inheritence
David M. Lloyd
david.lloyd at redhat.com
Tue Feb 9 07:47:41 PST 2010
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:
> 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 22.214.171.124:
126.96.36.199 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.
* 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.
However, later on in 188.8.131.52:
* 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.
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?
More information about the compiler-dev