The Java "Code Too Large" Problem: Reproduced and Analyzed
I came across an interesting demonstration and analysis of the Java "code too large" error in a post by Dustin Marx, Reproducing "code too large" Problem in Java. In the post, Dustin describes his effort to intentionally produce the "code too large" error. Why would someone do this?
In this case, it is because I always understand things better when I tinker with them rather than just reading about them and because doing so gives me a chance to demonstrate Groovy, the Java Compiler API (Java SE 6), and javap.
And off Dustin goes. His first discovery is that 65535 bytes of compiled byte code is the number that produces the "code too large" error. And these 65535 bytes have to be the compilation of a single method.
Now, realistically, what programmer would ever create a single method that compiled down to 65535 or more bytes? No one I've ever met. Yet, the "code too large" problem does actually exist "in the wild" (as Dustin calls it) -- specifically, it can happen when code is generated by, for example, Groovy.
To analyze the problem, Dustin built a Groovy script that:
generates a Java class that isn't very exciting. However, the class will have its main function be of an approximate size based on how many conditions I tell the script to create. This allows me to quickly try generating Java classes with different
main()method sizes to ascertain when the
main()becomes too large.
After the script generates the Java class, it also uses the Java Compiler API to automatically compile the newly generated Java class for me. The resultant
.classfile is placed in the same directory as the source
The Groovy script generates a very simple Java class consisting of a set of conditional statements. Dustin found the maximum number of conditionals that would produce a runnable class, then used the
javap tool to analyze the class file.
Dustin then presents key snippets from the output of
From the snippets of javap output shown above, we see that the highest
Codeoffset (65512) for this function pushing the limits of the method size was getting awfully close to the magic 65535 bytes (
Short.MAX_VALUE - Short.MIN_VALUE).
Dustin has named his blog Dustin's Software Development Cogitations and Speculations, and says he uses it as a way to document things for his own future reference, while also providing information to help other developers. For example, his post Favorite Development Cheatsheets is a convenient page to bookmark, since there he's placed links to many useful quick references for Java and other technologies.
Other recent posts investigate
BigDecimal conversion in Java and Groovy, and commentary on the "java is dead" discussion. There are also posts like Using Groovy to Check Seventh Grade Homework.
Dustin Marx does some interesting investigations and documents them well in his blog. I've subscribed and look forward to seeing what he investigates next.
Code conventions and standard software development wisdom dictate that methods should not be too long because they become difficult to fully comprehend, they lose readability when they get too long, they are difficult to appropriately unit test, and they are difficult to reuse. Because most Java developers strive to write highly modular code with small, highly cohesive methods, the "code too large" error in Java is not seen very often. When this error is seen, it is often in generated code...
Matt Givney describes Unit Testing Java with Groovy:
Much of the development I do for my clients is in Java. While I am still very much a fan of java, it is not without it's complexity. Groovy, on the other hand, builds on java to abstract and simplify a lot of the things we do in java. One particular place that I love using groovy to enhance a java project, is in unit testing. It's simplified syntax, built-in support for mocking and stubbing and meta programming makes unit testing java a complete cinch. In this installment of the Weekly Give, I am going to show an example of using the Groovy StubFor class to stub java method...
Peligritalks about an Expired Certificate in GlassFish Keystore:
One of the authority certificates in the Glassfish truststore expired on Jan 7, 2010. This is generating a (verbose and somewhat scary) error message on startup. You can just ignore the message, wait - the expired root was removed in update 18 of Java SE 6 and will be removed in later patches of GlassFish Server - or...
John Ferguson Smart announces A new Java Power Tools Newsletter is out: Web application testing strategies with Selenium:
In this issue we will be looking at how automated web testing fits into the larger picture. In particular, we will look at how you can use Selenium in different ways for different types of testing...
Hamada Zahera posted get the best for SCJP ?:
Spotlight is Alexis Moussine-Pouchkine's Testing with the GlassFish Maven plugin and JavaDB Embedded
Now SCJP certification become one of the most important sun certifications for java and it's simple to take it ,coz SUN will consider you as a Java programmer .There are many JProgrammers didn't take this certification although they are very well ,but taking this certification become more important than before specially to raise your rank as a programmer and also it's bonus for you to find better job than you have...
In the Forums,
lmcjome is seeing Excessive memory (280K) per connection in grizzly: "Hi. We are doing some benchmarking with glassfish comet/grizzly on SUSE linux 2.6.x. During our prototyping, we established 10000 connections and found that memory consumption is 280K/connection. We ran jprofiler (see attachments) and found that "byte" is consuming most of the memory. We did a heap scan to see what objects are using byte and found that 99% of this use is by com.sun.grizzley.util.WorkerThreadImpl.run..."
mahdi_hijaziwonders if an LWUIT application has a List problem or bug?: "Hi to you all. I was trying to make a simple list demo when I got this unexpected behavior. I do not need the form to cyclic the focus, so I use the setCyclicFocus( false ), but when I hit the down key on the last item on the list it gets back to the first component, why this happens? ..."
tdbuchananis getting a JAX-WS MTOM Applet OutOfMemoryError: "I have an applet that uses jaxws proxy classes with MTOM enabled to upload and download files from a WCF service (Netbeans 6.8 with the Metro 2 libraries and jdk/jre 1.6.18). I can upload large files to the WCF service just fine, but when I try to download a large file I receive an OutOfMemoryError with the following stack trace..."
Our current Spotlight is Alexis Moussine-Pouchkine's Testing with the GlassFish Maven plugin and JavaDB Embedded: "Having GlassFish v3 usable in embedded mode made it easy to create a maven plugin with multiple goals (see this previous entry). This in turn makes it easy to configure the plugin for maven-driven unit testing. Here's an example..."
This week's java.net Poll What is your favorite Oracle/Sun supported IDE?. Voting will end this Friday.
We've just published a new java.net Feature Article, Maven Repository Managers for the Enterprise, by John Smart. We're also featuring Jeff Friesen's Reading Newsfeeds in JavaFX with FeedRead, in which Jeff demonstrates how to apply JavaFX's RSS and Atom newsfeed capabilities to create a snazzy little JavaFX app that can run stand-alone or in a browser.
The latest Java Mobility Podcast is Java Mobile Podcast 92: MIDP 3.0 in Depth: Tutorials and Demonstrations: Excerpts from the JavaOne 2009 MIDP 3.0 In Depth: Tutorials and Demonstrations session with Roger Riggs, Lakshmi Dontamsetti and Stan Kao.
Current and upcoming Java Events:
- January 25: Developing Java Web Applications
- February 4-6: FOSDEM 2010
- March 17-19: TheServerSide Java Symposium 2010
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
-- Kevin Farnham