6908259: Covariance bug for multiple interface inheritence

[Maurizio Cimadamore]

Neal Gafter wrote:
> Maurizio-
>
> Can you please tell me what JLS3 rule justifies failing to compile
> T6294779c.java?  I was not able to find anything.
>   
I don't recall the specific discussion that led to this... in any case 
in that example, there's no method inherithed by I4, whose return type 
is compatible with all the other override equivalent signatures:

9.4.1:

"It is possible for an interface to inherit several methods with 
override-equivalent signatures (§8.4.2) 
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#38649>. 
Such a situation does not in itself cause a compile-time error. The 
interface is considered to inherit all the methods. However, one of the 
inherited methods must must be return type substitutable for any other 
inherited method; otherwise, a compile-time error occurs (The |throws| 
clauses do not cause errors in this case.)"

8.4.5:

"A method declaration d1 with return type R1 is 
return-type-substitutable for another method d2 with return type R2, if 
and only if the following conditions hold:

    * If R1 is a primitive type, then R2 is identical to R1.
    * If R1 is a reference type then:
          o R1 is either a subtype of R2 or R1 can be converted to a 
subtype of R2 by unchecked conversion (§5.1.9), or
          o R1 = | R2 |.
    * If R1 is void then R2 is void.
"

Which, I think, imply that T6294779c  must be rejected

Maurizio
> Cheers,
> Neal
>
> On Tue, Feb 9, 2010 at 2:10 AM, Maurizio Cimadamore
> <Maurizio.Cimadamore at sun.com> 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:
>>
>> class T6294779b {
>>
>> interface I1<E> {
>> List<E> m();
>> }
>>
>> interface I2<E> {
>> Queue<E> m();
>> }
>>
>> interface I3<E> {
>> LinkedList<E> m();
>> }
>>
>> interface I4<E> extends I1<E>, I2<E>, I3<E> {}
>> }
>>
>> In this case, I4 is well-formed as one of the implementing interfaces ---
>> namely I3 --- is defining a method which is compatible with all other
>> signatures from I1,I2.
>>
>> Maurizio
>>     
>>> - DML
>>>
>>>       
>>