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 .class file is placed in the same directory as the source .java file.
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 javap:
From the snippets of javap output shown above, we see that the highest Code offset (65512) for this function pushing the limits of the method size was getting awfully close to the magic 65535 bytes (216-1 or 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.
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...
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...
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...
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...
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_hijazi wonders 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? ..."
tdbuchanan is 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..."
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
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.
Previous Topic
