Reiner Saddey’s Place

Bad Habits Die Hard - How to Prepare Java Apps for Full Speed Debugging

Posted on March 15th, 2008 by Reiner.
Categories: English, Computers.

Deutsche Fassung bei Debuggen von Java Anwendungen - auf der Überholspur! 

When instrumenting your Java application for remote debugging, a commonly used set of VM parameters brings your application to a crawl, as it disables just-in-time compiliation and enforces interpeter-only mode, e.g.:

-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
-Djava.compiler=NONE 

Starting with Java 1.4, it is neither required nor advisable to disable the Java just-in-time compiler,

so just remove the -Djava.compiler=NONE:

-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

Thus, you are able to prepare your application (e.g. JBoss) for debugging, and there will be no perceivable overhead unless you actually connect your debugger to the debuggee (using remote debugging). And even while debugging, the Java just-in-time compiler will speed up your application. That may be handy for test (or even production) environments that are supposed to both deliver full speed and still supply a back door for debugging once the need arises.

Even recent posts still promote the -Djava.compiler=NONE  antipattern, as in See how maven works inside - remote debugging plugins or Debugging your Maven Project in Eclipse.

And the bad -Djava.compiler=NONE habit may still be hidden within numerous configuration files or tools, as it even made its way into Sun’s Java 6 itself.  See -Djava.compiler=NONE and -Xdebug anachronisms unanachronistically disable full-speed debugging at Sun’s Bug Database.

0 comments.