JDK-4641955 : Javac can produce class files too large to validate or meet the JVM spec
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-02-22
  • Updated: 2002-02-22
  • Resolved: 2002-02-22
Related Reports
Duplicate :  
Description

Name: gm110360			Date: 02/22/2002


FULL PRODUCT VERSION :
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

FULL OPERATING SYSTEM VERSION :

Windows2000

ADDITIONAL OPERATING SYSTEMS :

Solaris too.



A DESCRIPTION OF THE PROBLEM :
if you make a method that is too big ( more than 65536
bytes ), it will produce the class file, and javap will be
able to decompile the class file, but the VM will give me
an error about the method being too big.

This is of course, only an issue when I have generated
code.  I have to fudge my generator to try not to produce
methods that are so large they do this.

I'm sure you are aware of this, but it could at least tell
me it can't compile, or pull some weird stack thing to try
to fix the problem, instead of just making an invalid class
file.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Make a class file that has 64536 instructions in a
single method
2. Compile it with Javac
3. Watch it break if you try to run the class in the VM

EXPECTED VERSUS ACTUAL BEHAVIOR :
At the very least, it should give me an error message
instead of pretending like it made a valid class file.
Optimally ( while I'm shooting the moon ), figure out a way
to break up the method and play with the call stack so as
not have an issue.  Or just lift the restriction of 65535
on future JVM releases.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.ClassFormatError: test (Code of a method lo
nger than 65535 bytes)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class test
{
public static void main( String args[] )
{
if ( args > 0 ) System.exit( 1 );
// ... repeated 65536 times ( it's not that hard, only 16 cut/pastes )
}
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
There is no work around I know of, other than don't write
big methods.
(Review ID: 143163) 
======================================================================

Comments
PUBLIC COMMENTS .
10-06-2004