Bug ID: JDK-4786977 REGRESSION:Unable to use Xerces2 with mantis(Illegal UTF8 string in constant poo

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.2 b14Fixed

###@###.### 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.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b14 mantis-beta

14-06-2004

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.

11-06-2004