Yes, I just brought it as an easier to understand example. JVM must also enforce the Java access rules, one of them is that “protected” members can only be accessed by either members of the same package or subclasses. Verifier cannot check the subclass restriction fully, therefore INVOKEVIRTUAL does an extra check (quoted):

Finally, if the resolved method is protected (§4.6), and it is either a member of the current class or a member of a superclass of the current class, then the class of objectref must be either the current class or a subclass of the current class.

String[] is obviously *not* a subclass of XMLEntityManager therefore this call should not be allowed. If you check the bug reports I’m referring, it is clear that the JVM engineers are aware that this is a bug.

Of course that’s not going to compile, but that’s governed by the Java _Language_ Spec, not the _JVM_ Spec, isn’t it?

So if we stick to the JVM and the byte code, it does seem to me that INVOKEVIRTUAL is doing what it’s supposed to do: dispatching to the right version at runtime, instead of going with whatever is nominally passed to it.

Actually most often that’s a terrible idea. Backwards-compatibility is very important, unless you want to get up at 3 AM because the production server doesn’t work properly after the latest Java update.

My point is more that people who think that Java spec is all there is to Java are greatly oversimplifying things.

You are missing the point. If you write this code in Java it won’t even compile:

public String[] getRecognizedProperties() {
  return (String[])(((Object)
    RPROPERTIES).clone());
}

This causes big problems when it comes time to fix it since it’ll break existing code bases. I say, it’s better to just fix things. Sometimes, we should just let go of backward compatibility.

Invokevirtual does dispatching based on the runtime type of the target object. So where the byte code nominally shows INVOKEVIRTUAL Object.clone() : Object[], could it be that it’s actually dispatching to Array[].clone()?

If that is true, then according to the JLS 6.4.5, the clone() method on all array types is actually public.

That might be one way to explain it. :)