execution fails with IncompatibleClassChangeError

Remi Forax forax at univ-mlv.fr
Tue Dec 18 08:54:38 PST 2012


On 12/18/2012 05:14 PM, Maurizio Cimadamore wrote:
> On 18/12/12 15:51, Brian Goetz wrote:
>> Yes, this is a known bug with constructor refs to private nested
>> classes.  We are currently trying to figure out whether the solution
>> needs to come from the compiler or the VM.  (In the meantime, you can
>> make the Bar constructor but not class public, which should get you past
>> your current problem without opening additional security holes.)
> I think that, since this is a bug, there's no rush to get a fix in while
> we are figuring out what's the better way to fix it. If the outcome of
> the discussion is that we'll have to change the compiler, we'll do that
> when the time comes. It doesn't seem a super common issue anyway.

The root cause of this bug is the infamous 4071957
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
and to make a long story short, the EG of JSR 292 has decided to align 
the semantics of method handles on the reflection API on that subject.

>
> Maurizio

Rémi

>> On 12/18/2012 6:38 AM, 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