orig synopsis:  "Method byte code size is too small"  (filed against 1.2.1_03 java_solaris)

Currently the size of a Java method is limited to 65535 bytes.  Is this limitation going to be removed.  If so when?  Do you have a work around?

(see also bug # 4034989 and others)
(Review ID: 93793) 
======================================================================




java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

Virtual machines do not load methods with more than 64K bytes.
This is a big problem because the java code in question is not hand written, but is generated by automatic translators and code generators.


(Review ID: 118726)
======================================================================

N/A

Tim, is this an issue with JDK 1.4? If not then can we close this one out?


  xxxxx@xxxxx   2001-11-01

We will be considering this as part of a JCP initiative for 1.5.

  xxxxx@xxxxx   2002-10-22

Agree.

Compiling some jsp's creates _jspservice methods that are 
larger than 64k.  java.lang.VerifyError is thrown, have not 
found a workaround yet.

We bumped into this bug too when we tried to run our web 
application under Tomcat 4.0.
We think that we might be able to overcoem this by using 
<jsp:include> tags, but we haven't tried this yet.

This is still a problem with JDK 1.4.1.  The JSP generates a _jspservice mthod which is too large.  Since this is a generated method we can't break it up by hand.  When will this be fixed?

We're running into the same problem with our automatic source code generator.  It's generating scientific code, not JSPs.  Kudos to Sun engineers for putting this ridiculous arbitrary limit on size of method code that severly limits the use of source code generators.  A job well done!  It's also good to see that this issue has had so much work done on it in the SIX YEARS since it was first reported.

Dear friends at Sun,

  Like zcox123, I also have a code generator that sometimes goes over the limit.  According to section 4.10 of the JVM spec we have this limit because some indicies in class file attributes are two bytes long (short). Please move up to four bytes or add parallel attributes that use four-byte values.

Hi, It's year 2007.... JDK 1.5.0 - still big problem - We are unable to create big JSPs...... Any official statement from Sun?

thanks,

Branislav

Arrrggg...Java 1.6, I have this problem and search in the net for a solution - find this page only to see that it is there since 1999. Will this ever be fixed in this millenia?

It would be very nice if this limit could be removed. There are already byte codes for handling >64K methods (goto_w and jsr_w).

This is not only a problem for JSP and similar template languages.

Nowadays it's common to compile other languages than Java to JVM byte code, and in some cases it might be useful to compile a whole program into a single JVM method, since the Java invoke method style is incompatible with the language you want to compile. Procedures/functions/methods can then be implemented using the jsr (or jsr_w) and ret bytecodes.

Some say that the new invokedynamic bytecode will solve this. It will certainly be a good solution for some languages, such as Python and Ruby. But I'm not sure that it will work smoothly for languages that are even more different, such as Haskell or Prolog.

I just realized that support for the jsr and jsr_w bytecodes has been dropped in JavaSE 6 :-(

I have submitted an RFE for restoring support for jsr and jsr_w, and that's connected to this RFE. It would probably not be worthwhile to do only one of them, both are needed in order to provide good support for compiling other languages to JVM bytecode.

The RFE for jsr/ret is now registrered as #6610567, but it doesn't seems like Sun want to fix it :-(

I've got an applet that is stuck with this bug.  This is a pig and might end our developement on Java for good!

What a shame!

is this limitation still applicable for JDK 1.4.2??

In case when it appears in enum initializer we might split elements into sub-initializer, to avoid this problem.