Please reply to my JDK-8059640 issue comment

[Georgiy Rakov]

Just a friendly reminder,

Thanks, Georgiy.

On 09.07.2015 2:23, Dan Smith wrote:
>> On Jul 6, 2015, at 10:13 AM, Georgiy Rakov <georgiy.rakov at oracle.com> 
>> wrote:
>>
>> Hello,
>>
>> could you please reply to my following comment 
>> <https://bugs.openjdk.java.net/browse/JDK-8059640?focusedCommentId=13817637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13817637> 
>> I made to JDK-8059640; quoting it:
>>
>>     Suggested spec change states that 15.13.3 will contain following
>>     assertion:
>>
>>     LinkageError may occur due to inconsistencies between compile
>>     time and run time (in the referenced method, the functional
>>     interface, or the argument types of either).
>>
>>     The details are provided in parenthesis: "in the referenced
>>     method, the functional interface, or the argument types of
>>     either". It seems that these details don't extend to following
>>     case specified in jls-15.12.4.3-120:
>>
>>     If the invocation mode is interface, then the implementation must
>>     also check that the target reference type still implements the
>>     specified interface. If the target reference type does not still
>>     implement the interface, then an IncompatibleClassChangeError occurs.
>>
>>     I believe they should.
>>
>> Namely, could you please tell if you agree that spec change suggested 
>> in the issue description doesn't extend to the case specified in 
>> jls-15.12.4.3-120. If you agree I would appreciate greatly if you 
>> could modify the suggested spec change so that it extends to 
>> jls-15.12.4.3-120 case.
>>
>
> I think these are two different kinds of errors.
>
> JDK-8059640 is about BootstrapMethodErrors that can occur upon 
> *evaluation of* a method reference expression, but that aren't 
> specified to occur.
>
> The check you describe is an ICCE that can happen upon *invocation of* 
> the method of an object derived from a method reference expression.
>
> Please correct me if you're seeing different behavior, but my 
> expectation is that the invocation will behave exactly as specified: 
> per 15.13.3, the body of the method is via an invocation that proceeds 
> according to 15.12.4.3; per 15.12.4.3, the ICCE can occur.
>
> Example:
>
> interface I { int x(); }
> interface Func { int apply(I arg); }
>
> Func f2 = I::x;
> System.out.println(f2);
> // no errors yet
> System.out.println(f2.apply(new C()));
> // ICCE if C was originally declared to implement I, but no longer does
>
> So I don't think there's a bug here, either in the spec or the 
> implementation.
In the example you provided inconsistency occurs at the point of 
*invocation of* the method of an object derived from a method reference 
expression. But we can consider another example which contains 
inconsistency occurring at the point of *evaluation of* a method 
reference expression:

    interface MethodSupplier {    void m(int a);}

    interface MyFunctionalInterface {int invokeMethodReference(int a);}

    class MethodSupplierImpl implements MethodSupplier {
         @Override
         public void m(int a) {}
    }

    MyFunctionalInterface instance = null;
    MethodSupplier ms = new MethodSupplierImpl();
    instance = ms::<Integer>m; //inconsistency occurs here
    instance.invokeMethodReference(1);

Currently the behavior is Ok, that is provided MethodSupplierImpl is 
recompiled without implementing MethodSupplier, ICCE is thrown when 
executing "instance.invokeMethodReference(1)". But potentially it looks 
possible for the error to be thrown during executing "instance = 
ms::<Integer>m" and suggested spec change doesn't encompass this case. 
So I wonder if it's worth encompassing such case for the suggested spec 
change.

Could you please also tell if I understand correctly that suggested spec 
change specifies the possibility of throwing LinkageError during 
*evaluation of* method reference and not during *invocation of* the 
method of an object derived from a method reference expression.

Thank you,
Georgiy.

>
> —Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150727/5da7b745/attachment-0001.html>