At present, I am at client site where the debug flag is not turned on for all production builds. Recently, there is an increasing number of requests from developers who would like to have the debug flag turned on for all Java builds including production builds.

Having worked both as a developer and an SCM expert, I know that there is a clear recommendation for the debug flag not being turned on for production builds for C applications. However, in this case, the request to turn on the debug flag for all builds including production is made by developers of Java applications.

I can see both sides - the operations and infrastructure teams do not want the debug flag to be turned on in production. The developers would like debug to be turned on to resolve production issues quickly. Also, the developers say that they do not have access to start the JVM on a machine and so will not be able to manipulate the values of the variables for the Java application at runtime - so there should be no security risks.

My recommendation is that we can have the debug flag turned on for preproduction environments but not for production builds. A production outage should be rare - whether it is a Java or C application, adequate testing should be done upfront so that you don't have to debug in production.

I think there are three potential issues with running debug compiled Java code in production: performance, security and process

In Java, the compiled classes are only byte code that is interpreted by the JVM, which then optimizes code for execution with the JIT compiler (Just In Time). The JVM then actually monitors code and code that is executed often is further optimized with the Hotspot compiler, because presumably it found a "hot spot".

So, runtime optimization is not affected in the same way as for a C compiler, but it still has to keep track of line numbers and other information according to your debug options. This has to have some performance degradation, but how much? Word on the street is that the performance cost is minimal, but no guarantees. Word from a developer is that their performance problems with their application dwarf any possible cost from compiling in debug. Still, a quantitative answer is elusive.

Regarding security, the JVM itself, and by extension the appserver, has to be configured to allow debugging regardless of how the code is compiled. Additional services must intentionally be started and ports opened up. So there is some protection there. But, I'm not a hacker in that way. It is at least not as obvious how to change values in Java as compared with the C case.

The biggest _object_ion of most process oriented businesses is the implication of compiling debug on the stability of the production environment. Some will maintain that production is simply not the place to debug code. Now, it can be argued that having a log file print out the source code name and line number in a log file is not really debugging. It is reporting. It is a little tough to explain those differences to management sometimes.

HTH. Thanks to Nick for info on the JVM runtime optimizations...