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?
Perhaps not; the VMs need to be fixed and this can be conditioned on which -target we're generating code for.
The bug 4398781 has been opened against the VM.
It turns out that when we tried to fix this we generated bad code. There is no known VM problem yet.
Well, the VM should reject what javac currently generates as it is
a protection violation!
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.
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.