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


ADDITIONAL OS VERSION INFORMATION :
Debian GNU/Linux 2.6.6-2-686
Windows 2000

A DESCRIPTION OF THE PROBLEM :
This bug occurs when a class file contains a SourceDebugExtension attribute larger than 65535 bytes. In that case, running the java virtual machine with the debugger enable (with -Xdebug) causes a java.lang.InternalError to be thrown, as specified below.

According to the Java Virtual Machine Specification, attributes have a length coded on 4 bytes. Furthermore, JSR 045, which specifies the SourceDebugExtension attribute, does not specify such limitation on the length of the attribute. It even states that "The SMAP allows a virtually unlimited number of source files per stratum." It therefore looks like the current implementation violates the specifications.

Compilers for non-Java languages, which are the explicit audience of the SourceDebugExtension attribute, are at liberty to compile multiple source files into the same class file. In that case, it is very easy to need more than 64K map to represent source line information in that class file. We have indeed run into that situation ourselves. Therefore, we would greatly appreciate if this bug was fixed in a timely fashion.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Create a class file with a SourceDebugExtension attribute larger than 65535 bytes and some main method.
2) Run that class with 'java -Xdebug'.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The method should be executed normally.
ACTUAL -
  Program execution was aborted by the java.lang.InternalError exception described below.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.InternalError: name is too long to represent
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This cannot be triggered by java source code, as the crucial element is the large SourceDebugExtension attribute.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The SourceDebugExtension attribute can be stripped out prior to execution, losing the benefits of JSR 045. Similarly, the 1.3 versions of the JVM do no fail in this situation, most likely because they ignore that attribute, therefore also losing the benefits of JSR 045.
  xxxxx@xxxxx   2005-07-06 03:52:29 GMT

N/A

N/A

is there any work being done on this? it would be really really great if this was resolved.

Over a year passed since the bug was filed. It is still present 1.5.0_06. Please, Please fix this !

And now in 2007 we have this bug also within 1.6.0_01

Please fix this !!!! With Tomcat and Big JSF pages (over 3M) it dasn't work. 

Prevents me from compiling quite a big JSP (generated Java code about 4MB), too!