execution fails with IncompatibleClassChangeError

Remi Forax forax at univ-mlv.fr
Tue Dec 18 09:00:13 PST 2012


On 12/18/2012 05:59 PM, Brian Goetz wrote:
> Easier would be to do what we do for other kinds of method refs that 
> can't cleanly be implemented as an MH (such as defender super calls), 
> which is to desugar to a method (basically turn the MR back into its 
> equivalent lambda.)
>
> Since you asked... :)  The underlying problem comes from the 292 spec, 
> which nest-mate accessibility for MHs is different from the rules in 
> the source language.  292 could fix this too...hint...

yes, I know, we have decided to not fix it.
The 'Right' way to fix that is to have a real class format that embodies 
several classes in the same classfile.

Rémi
(I hate when the mailing list is lagging).

>
> On 12/18/2012 11:39 AM, Remi Forax wrote:
>> On 12/18/2012 01:08 PM, Maurizio Cimadamore wrote:
>>> Thanks for the report. We are aware of the issue and working on a fix.
>>
>> yes, the compiler needs to generate an accessor for it.
>>
>> Rémi
>>
>>>
>>> Maurizio
>>>
>>> On 18/12/12 11:38, Anna Kozlova wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> Running the following class
>>>>
>>>> {code}
>>>>
>>>> public class FooBar {
>>>>
>>>>        private static final class Bar {
>>>>
>>>>            private Bar() {
>>>>
>>>>            }
>>>>
>>>>        }
>>>>
>>>>
>>>>
>>>>        private interface I {
>>>>
>>>>            Bar create();
>>>>
>>>>        }
>>>>
>>>>
>>>>
>>>>        static void foo(I intf) {}
>>>>
>>>>
>>>>
>>>>        public static void main(String[] args) throws Exception {
>>>>
>>>>            foo(Bar::new);
>>>>
>>>>        }
>>>>
>>>> }
>>>>
>>>> {code}
>>>>
>>>>
>>>>
>>>> fails with
>>>>
>>>> Exception in thread "main" java.lang.IncompatibleClassChangeError
>>>>
>>>>                    at
>>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa 
>>>>
>>>> tives.java:383)
>>>>
>>>>                    at p.FooBar.main(FooBar.java:18)
>>>>
>>>>                    at 
>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>>
>>>>                    at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 
>>>>
>>>> )
>>>>
>>>>                    at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl 
>>>>
>>>> .java:43)
>>>>
>>>>                    at java.lang.reflect.Method.invoke(Method.java:474)
>>>>
>>>>                    at
>>>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
>>>>
>>>> Caused by: java.lang.IllegalAccessException: member is private:
>>>> p.FooBar$Bar.<init>()void/invokeSpecial, from p.FooBar
>>>>
>>>>                    at
>>>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732)
>>>>
>>>>                    at
>>>> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) 
>>>>
>>>>
>>>>                    at
>>>> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav 
>>>>
>>>> a:1243)
>>>>
>>>>                    at
>>>> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles 
>>>>
>>>> .java:1270)
>>>>
>>>>                    at
>>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa 
>>>>
>>>> tives.java:381)
>>>>
>>>>                    ... 6 more
>>>>
>>>>
>>>>
>>>> If I convert method reference to lambda expression or anonymous class
>>>> everything works correctly.  Checked with b68.
>>>>
>>>>
>>>>
>>>> Thank you
>>>> Anna
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>



More information about the lambda-dev mailing list