Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2058828 | 1.4.2 | Jane Loizeaux | P3 | Closed | Fixed | mantis |
JDK-2058827 | 1.4.1_01 | Jane Loizeaux | P3 | Closed | Fixed | 01 |
JDK-2058826 | 1.4.0_03 | Jane Loizeaux | P3 | Closed | Fixed | 03 |
JDK-2058825 | 1.3.1_06 | Jane Loizeaux | P3 | Closed | Fixed | 06 |
JDK-2058824 | 1.2.2_14 | Jane Loizeaux | P3 | Closed | Fixed | 14 |
Name: gm110360 Date: 09/19/2002
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/redhat-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.ibm.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.ibm.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)
======================================================================
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/redhat-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.ibm.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.ibm.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)
======================================================================
- backported by
-
JDK-2058824 REGRESSION: Array.clone() broken in 1.4.1-b21
-
- Closed
-
-
JDK-2058825 REGRESSION: Array.clone() broken in 1.4.1-b21
-
- Closed
-
-
JDK-2058826 REGRESSION: Array.clone() broken in 1.4.1-b21
-
- Closed
-
-
JDK-2058827 REGRESSION: Array.clone() broken in 1.4.1-b21
-
- Closed
-
-
JDK-2058828 REGRESSION: Array.clone() broken in 1.4.1-b21
-
- Closed
-