United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4329886 : Clone() on arrays compiled incorrectly

Details
Type:
Bug
Submit Date:
2000-04-12
Status:
Closed
Updated Date:
2003-04-12
Project Name:
JDK
Resolved Date:
2002-09-02
Component:
tools
OS:
generic
Sub-Component:
javac
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0
Fixed Versions:
1.4.2 (mantis)

Related Reports

Sub Tasks

Description
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

                                    

Comments
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


                                     
2004-06-14
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.
                                     
2004-06-10
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
                                     
2002-05-24



Hardware and Software, Engineered to Work Together