Code review request for 4881419 The type of X[].clone() should be X[]

David Holmes David.Holmes at
Tue Sep 7 07:35:16 UTC 2010

Jeroen Frijters said the following on 09/07/10 13:58:
> Martin Buchholz wrote:
>> On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jeroen at> 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

More information about the core-libs-dev mailing list