United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4786977 : REGRESSION:Unable to use Xerces2 with mantis(Illegal UTF8 string in constant poo

Details
Type:
Bug
Submit Date:
2002-12-02
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2003-01-22
Component:
hotspot
OS:
linux,generic
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:
1.4.2 (b14)

Related Reports
Duplicate:

Sub Tasks

Description
###@###.### 2002-12-02

J2SE Version (please include all output from java -version flag):
  java version "1.4.2-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b08)
  Java HotSpot(TM) Client VM (build 1.4.2-beta-b08, mixed mode)

Does this problem occur on J2SE 1.3 or 1.4?  Yes / No (pick one)
  Bug appears since 1.4.2-beta-b06, works fine with build04

Operating System Configuration Information (be specific):
  Linux *** 2.4.19-xfs #5 SMP GNU/Linux

Bug Description:
  Java runtime complains about java.lang.ClassFormatError (Illegal UTF8 
  string in constant pool). Unable to use Xerces2 with j2sdk 1.4.2-beta-b06
  and -b08 (-b04 works)

Steps to Reproduce (be specific):
  1. Get xercesImpl.jar (e.g. Xerces 2.2.1 from   
      http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.1.tar.gz)

  2. Execute java -classpath xerces2/xercesImpl.jar org.apache.xerces.impl.xpath.regex.ParserForXMLSchema

Exception in thread "main" java.lang.ClassFormatError: org/apache/xerces/impl/xpath/regex/ParserForXMLSchema (Illegal UTF8 string in constant pool)
	at java.lang.ClassLoader.defineClass0(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:504)
	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)
Could not find the main class. Program will exit.

Works fine with 1.4.2-beta-b04 and earlier.


                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis-beta

FIXED IN:
mantis-beta

INTEGRATED IN:
mantis-b14
mantis-beta


                                     
2004-06-14
EVALUATION

This is an extremely unfortunate interaction of an old compiler bug (4324508)
with a recent strengthening of the JVM class file checker.  It is certainly
not a compiler bug anymore, as the compiler has generated canonical UTF8 since
4324508 was fixed.  However, any class files that were generated when that bug
still existed now fail to run on 1.4.2.

Here is a much simplified test case.  Compile on 1.3.0 and run on 1.4.2.

  public class T {
    String s = "\u0700";
    public static void main(String[] args) {}
  }

It seems that for backward compatibility we must allow these cases of
noncanonical UTF8 in class files.

Reassigning to runtime.

###@###.### 2002-12-02



###@###.### 2002-12-10
Related problem - code compiled with one compiler will not link with
code compiled with the other if symbols contain different UTF8
encodings of the same name.
Waiting for discussion.
                                     
2004-06-11



Hardware and Software, Engineered to Work Together