FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :
glibc-2.2.4-19.3
Linux quaffle 2.4.9-31smp #1 SMP Tue Feb 26 06:55:00 EST 2002 i686 unknown
/etc/ customer -release

A DESCRIPTION OF THE PROBLEM :
There was a regression between 1.4.1 release candidate (b19) and final version (b21) in accepting code
compiled by the jikes compiler.  Jikes 1.16 emits <array>.clone() rather than Object.clone() in the
bytecode, in accordance with JLS 13.1 (javac still does not do this, but that is a subject for a different
bug report).

With earlier VMs, the sample program below worked, but now it causes a VerifyError.


This bug may require specification clarification, in both the JLS and the JVMS.  See also my longer
description of this issue at http://groups.yahoo.com/group/java-spec-report/message/764.



REGRESSION.  Last worked in version 1.4.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the program below with jikes 1.16 or greater (jikes is obtainable from
http://www-124. customer .com/developerworks/project/showfiles.php?group_id=10). Compilation with javac does not
show this bug - you need jikes (or else manually assembling a .class file to call invokevirtual
String[].clone()).

$ jikes Foo.java
$

2. Execute with the b19 or earlier builds
$ /opt/java/bin/java -version
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)
$ /opt/java/bin/java Foo
[Ljava.lang.String;@1fcc69
$

3. Try again with 1.4.1 final candidate.
$ java version
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
$ java Foo
Exception in thread "main" java.lang.IllegalAccessError: tried to access method
java.lang.Object.clone()Ljava/lang/Object; from class Foo
        at Foo.main(Foo.java:3)
$


EXPECTED VERSUS ACTUAL BEHAVIOR :
The program should always execute. However, the 1.4.1 final regression causes a VerifyError:


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.IllegalAccessError: tried to access method
java.lang.Object.clone()Ljava/lang/Object; from class Foo
        at Foo.main(Foo.java:3)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class Foo {
  public static void main(String[] args) {
    System.out.println(args.clone());
  }
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Jikes 1.16 cannot be used if the targetted VM is java 1.4.1-b21. A bug was raised against jikes
(http://www-124. customer .com/developerworks/bugs/?func=detailbug&bug_id=3290&group_id=10), so future versions may
emit Object.clone() the way javac does currently, but I think this violates JLS 13.1.

Meanwhile, the user can revert to an older VM, or can do the following to avoid the VerifyError when
compiling with jikes 1.16:
class Foo {
  public static void main(String[] args) {
    Cloneable o = args;
    try {
      o.clone();
    } catch (CloneNotSupportedException e) {
      assert false : "Impossible - array clones always succeed";
    }
  }
}

Release Regression From : 1.4.1
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 164758) 
======================================================================

N/A

VM wasn't honoring JVMS 2.15's special case for arrays:

  Arrays are objects, are dynamically created, and may be
  assigned to variables of type Object (§2.4.7). All methods
  on arrays are inherited from class Object except the clone
  method, which arrays override. All arrays implement the
  interfaces Cloneable and java.io.Serializable.

  xxxxx@xxxxx   2002-09-23

See also bug 4329886, which shows that javac 1.4.1's 
behavior is wrong, and that jikes is correct.

The suggested code (with Cloneable = ...) cannot be compiled - any other suggestion (besides cloning 'manually' the array)?

I just downloaded the 1.4.1_01 that was released yesterday, 
installed, and tested. This bug isn't fixed in 1.4.1_01 as far as 
I can tell.  IDLJ generates code with a String array clone 
operation that still fails the same way it did on 1.4.1.  I can 
provide quite a bit more detail to anyone interested...

I don't know what your problem is, but 1.4.1_01 fixed it for me.

steve olson, do you still see the problem?  Why eblake said
it's fixed?  Did you investigate on this yet?