Submitted On 05-JUL-2001
Compiling some jsp's creates _jspservice methods that are
larger than 64k. java.lang.VerifyError is thrown, have not
found a workaround yet.
Submitted On 18-NOV-2002
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.
Submitted On 26-MAY-2004
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?
Submitted On 14-MAR-2005
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.
Submitted On 31-AUG-2006
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.
Submitted On 01-FEB-2007
Hi, It's year 2007.... JDK 1.5.0 - still big problem - We are unable to create big JSPs...... Any official statement from Sun?
Submitted On 06-JUL-2007
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?
Submitted On 24-AUG-2007
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.
Submitted On 24-AUG-2007
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.
Submitted On 09-OCT-2007
The RFE for jsr/ret is now registrered as #6610567, but it doesn't seems like Sun want to fix it :-(
Submitted On 08-DEC-2008
I've got an applet that is stuck with this bug. This is a pig and might end our developement on Java for good!
Submitted On 15-APR-2009
What a shame!
Submitted On 10-JUN-2009
is this limitation still applicable for JDK 1.4.2??
Submitted On 16-OCT-2009
In case when it appears in enum initializer we might split elements into sub-initializer, to avoid this problem.
Submitted On 03-NOV-2010
This should also be reported against 1.5.x and 1.6.x. Please update the recorded against field accordingly.
Could this be part of JDK 7? This is really important. Thank you.
PLEASE NOTE: JDK6 is formerly known as Project Mustang