Bug ID: JDK-4329886 Clone() on arrays compiled incorrectly

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.2 mantisFixed

Consider:

class ArrayClone {

  public static void main(String[] args) {
    args.clone();
  }
}

Compiling this with javac (1.3 version) and running javap on the resulting class
file, we get:

javap -c ArrayClone
Compiled from ArrayClone.java
class ArrayClone extends java.lang.Object {
    ArrayClone();
    public static void main(java.lang.String[]);
}

Method ArrayClone()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return

Method void main(java.lang.String[])
   0 aload_0
   1 invokevirtual #2 <Method java.lang.Object clone()>
   4 pop
   5 return


Note that the call to clone refers to Object rather than to the array type
String[]. This is wrong under both old and new JLS rules for compilation.
This only matters for illegal programs, so it is not a big deal.

gilad.bracha@eng 2000-04-12

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis

14-06-2004

PUBLIC COMMENTS Beginning with the 1.4.2 version of javac, the byte code generated for cloning an array uses the array's type as the qualifying type for the clone method invocation when -target 1.4.2 is specified. Although this is required by the language spec, previous versions of javac generated a call to Object.clone instead. That is incorrect for two reasons: first, it voiolates the JLS spec for binary compatibility, and second because the clone() method in Object is inaccessible. This is the only case in which an array type appears as a qualifying type in the byte code. We condition this bug fix on the -taret 1.4.2 flag because this code difference may cause problems for non-Sun VMs and byte-code processors. This new value for the -target flag is not documented elsewhere, nor do we expect it to be used widely.

10-06-2004

EVALUATION The old compiler (jdk 1.1.8 and jdk1.2) generates the same allegedly incorrect code. I seem to remember at one time that the new compiler generated code that referenced the 'clone' method of the array type, and that the resulting code didn't work. Are we sure that the VM is prepared to handle this? william.maddox@Eng 2000-04-21 Perhaps not; the VMs need to be fixed and this can be conditioned on which -target we're generating code for. neal.gafter@Eng 2000-12-14 The bug 4398781 has been opened against the VM. neal.gafter@Eng 2000-12-21 It turns out that when we tried to fix this we generated bad code. There is no known VM problem yet. neal.gafter@Eng 2001-01-24 Well, the VM should reject what javac currently generates as it is a protection violation! ###@###.### 2002-03-10 Due to an incorrect merge, the -target 1.4.1 support was removed from the compiler in Hopper, so I'm recommitting this to Mantis. All the engineering work is already in the compiler except for the -target 1.4.1 flag. But since this is going in to Mantis, the flag should be -target 1.4.2. ###@###.### 2002-05-24

24-05-2002