JDK-4787534 : jdk1.4.2 accepts invalid class files
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2002-12-03
  • Updated: 2003-01-08
  • Resolved: 2003-01-08
Related Reports
Duplicate :  
Description

Name: viR10068			Date: 12/03/2002


The javac compiler from JDK-1.3.1 generates incorrect values for the
symbols from the range '\u0080' to '\u07ff' (for example, the symbol 
"\u04d0" is coded as 0xE09390 instead of 0xD390 as required by 
JVMS ed 2. Chapter 4.4.7).

If:
  - java source file contains method name with the UNICODE symbols 
    from the range '\u0080' to '\u07ff'
  - the file is compiled by the javac from jdk1.3.1 
  - the class file version is changed from 45.3 (default value for jdk1.3.1)
    to 46.0
then the JVM from jdk1.4.2 will not reject this invalid class file
with the ClassFormatError (JVMS ed 2. Chapter 4.9.1).

If there is intent to accept class files generated by javac 1.3.1 for
compatibility reasons, then JVM should accept class files with the version
ID 45.3 and not vice versa.

To reproduce compile the example below by the javac1.3.1, change the
class file version from 45.3 to 46.0 in any hex-editor and run the
class file on the jdk1.4.2.
--------------------------- test.java ------------------------------
public class test {
    public static void main(String[] args){
        System.out.println(new test().a());
    }
    
    String a() {return "s";}

    String getStr00A\u04d0(){return "";}
}
--------------------------------------------------------------------
% java -version
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b07)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b07, mixed mode)
// if the version 46.0
% /export/ld25/java/dest/jdk1.4.2/solaris-sparc/bin/java test
s

// if the version 45.3
% java test
Exception in thread "main" java.lang.ClassFormatError: test (Illegal UTF8 string in 
constant pool)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:505)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
% 

======================================================================

Comments
EVALUATION ###@###.### 2002-12-16 Spec says we should not accept those characters -- This is already fixed under some other bug (?), and this is causing a severe regression in that common classes (XML parsers) are now failing because they contain the bad constants.
11-06-2004