Good catch. Thanks for the report.
In hindsight, this irregularity is expressed in the JVM in
LinkResolver::check_method_accessability:
329 // Special case: arrays always override "clone". JVMS 2.15.
330 // If the resolved klass is an array class, and the declaring class
331 // is java.lang.Object and the method is "clone", set the flags
332 // to public.
hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/interpreter/linkResolver.cpp
There do not seem to be any further such special cases in the code.
— John
On Oct 16, 2012, at 6:01 AM, Remi Forax wrote:
> Tracking a bug in the backport, I've discovered that I forget to have a
> special case for Object[].clone(),
> the backport currently reports that the method is protected
> (Object.clone is protected) thus not accessible.
>
> The latest jdk8 binary also have some trouble with array.clone too.
>
> public class JDKBug {
> public static void main(String[] args) throws Throwable {
> MethodHandles.lookup().findVirtual(Object[].class, "clone",
> MethodType.methodType(Object.class));
> }
> }
>
> Exception in thread "main" java.lang.InternalError
> at java.lang.invoke.MethodHandle.viewAsType(MethodHandle.java:1254)
> at
> java.lang.invoke.MethodHandles$Lookup.restrictReceiver(MethodHandles.java:1194)
> at
> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1214)
> at
> java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1198)
> at
> java.lang.invoke.MethodHandles$Lookup.findVirtual(MethodHandles.java:654)
> at fr.umlv.megamorph.JDKBug.main(JDKBug.java:9)
>
> cheers,
> Rémi
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
