Jeroen Frijters said the following on 09/07/10 13:58:
Martin Buchholz wrote:
On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jer...@sumatra.nl> wrote:
Sorry to be late with my comment, but as a VM implementer I can't
really agree with this modification. The return type of X[].clone() is
clearly Object, not X{]. That illusion is a javac compiler trick. IMHO
it belongs in the JLS not in the Object.clone() documentation.
I agree there is a little bit of cheating going on, but I don't agree
that the return type of X[].clone() is a "javac compiler trick". In
some sense all compile-time types are javac-created illusions.
Here's what javac generates:
public static void main(java.lang.String[])
Code:
0: aload_0
1: invokevirtual #2; //Method
"[Ljava/lang/String;".clone:()Ljava/lang/Object;
4: checkcast #3; //class "[Ljava/lang/String;"
7: iconst_0
8: ldc #4; //String
10: aastore
11: return
If you read this from the VM perspective (is there any other ;-)), you see that
the VM needs to provide a public clone method on the type String[] that returns
Object.
The previous text made this obvious, with the change, you explicitly need to
understand the (external) fact that the text is talking about javac behavior,
not a feature of the VM (or class library).
I agree that the change makes life easier for the Java developers that use
Javac (i.e. the Java programming language), but since the JVM tries to be a
more hospitable environment to multiple languages, I don't agree in favoring
the Java programming language like this in the API docs.
I must be missing something subtle here. Object.clone() is required to
return an object that is the same type as the object upon which clone()
was invoked. The change simply clarifies this fact for the case of arrays.
The fact that Object.clone() is implemented via a native call into the
VM is simply an implementation detail. I don't see how this
clarification changes the requirements that are placed on how the VM
implements this - it must return an object of the correct type.
David Holmes
