On 09/13/2013 03:38 PM, Joel Borggrén-Franck wrote:
I fully agree this will most probably occur in practice. But the situation is
more complicated for an invoke, since there must have been a A.m() present when
C was compiled in order to have an invokeinterface to be there in the first
place. Just adding a default to A won't trigger this since there won't be an
invokeinterface C.m().
Something like this might do:
Compile A { void m(); }, B {} and C {} together.
Compile A { } B { static m()} together
Compile A { default m(); }
Do you have a preference for how we should do this?
cheers
/Joel
Something like that, yes:
http://cr.openjdk.java.net/~plevart/jdk8-tl/StaticVsDefaultInterfaceMethods/StaticInterfaceMethodInWayOfDefault.java
It shows that VM throws IncompatibleClassChangeError if at invoke time
the search for method encounters a static method in it's path. Is this
correct behavior? Should reflection also throw a similar exception? This
could only be done when requesting a specific method (getMethod(name,
parameterTypes)), but what to do with getMethods() then?
Running using _v1 classes:
C.m() called
Running using _v2 classes:
Exception in thread "main" java.lang.IncompatibleClassChangeError:
Expecting non-static method StaticInterfaceMethodInWayOfDefault$B.m()V
at
StaticInterfaceMethodInWayOfDefault$TestTask$1.m(StaticInterfaceMethodInWayOfDefault.java)
at
StaticInterfaceMethodInWayOfDefault$TestTask.run(StaticInterfaceMethodInWayOfDefault.java:36)
at
StaticInterfaceMethodInWayOfDefault.main(StaticInterfaceMethodInWayOfDefault.java:55)
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:491)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Regards, Peter
