English 中文(简体)
Should Java programs compiled with debugging information not be used in a production system?
原标题:

Is there any reason I should avoid compiling in debugging information with Javac in my Java classes for use in a production server? Are there any speed or security concerns I should be aware of?

Please note that I am referring to debugging information like line numbers in stack traces, not the debug level of loggers.


Related Question:

最佳回答

Do you mean compiling with the debug option? Is there a performance difference between Javac debug on and off?

问题回答

Speaking as a developer then I would recommend leaving as much in as you possibly can get away with. The reasoning?

One day, you will encounter a bug in your program where the ONLY piece of information you have is a stack trace, and the bug cannot be reproduced on command, it was completely unanticipated by the original programmers, and it is YOUR job to fix it. The more information available to you in that stack trace the better! Leave all debug information in!

If you can, then use a logging framework (to get the stack traces to a file) which can provide information about the jar-file in which each class was found. Logback can do this, and I believe log4j can too.

You may not be allowed to include all this information, but I believe you should first yell and scream and say that it should be left in for contingency reasons.

Performancewise I believe that since HotSpot it hasn t mattered.

If you mean the line number info, for printing stack traces, then it is typically a good idea to keep that around. A customer can paste in the stack trace in a bug report for you to work with.

If you are really worried about the names of your methods being visible, you can use ProGuard or some other obfuscator. ProGuard has the nice property that it can de-obfuscate stack traces, so customers can still send them to you.

Obfuscation is not perfect, so if you don t want to spend the effort, there s nothing wrong with not doing it.

Depends on the excessiveness of the debugging and the performance sensitivity of your program. 90% of the world with moderate debugging shouldn t have to worry.

You can always use a preprocessor to eliminate the code too.

I agree with BalusC that loglevels in production can generally be set higher (less output) in production than in test. I think that entirely removing the logging would be counter productive. Even in production code errors occur, and you need the logging information to find out what happened.

Assert statements are also not that much of a problem, unless of course in a very performance sensitive piece of code. You should be able to leave them out completely as assert statements are generally for checking things which cannot occur (if used correctly). But going through the trouble, little as it is, to get them out is not really necessary.

I personally feel that the software, as installed in production, should be as close as possible to the development software, as that has been tested most often.





相关问题
Spring Properties File

Hi have this j2ee web application developed using spring framework. I have a problem with rendering mnessages in nihongo characters from the properties file. I tried converting the file to ascii using ...

Logging a global ID in multiple components

I have a system which contains multiple applications connected together using JMS and Spring Integration. Messages get sent along a chain of applications. [App A] -> [App B] -> [App C] We set a ...

Java Library Size

If I m given two Java Libraries in Jar format, 1 having no bells and whistles, and the other having lots of them that will mostly go unused.... my question is: How will the larger, mostly unused ...

How to get the Array Class for a given Class in Java?

I have a Class variable that holds a certain type and I need to get a variable that holds the corresponding array class. The best I could come up with is this: Class arrayOfFooClass = java.lang....

SQLite , Derby vs file system

I m working on a Java desktop application that reads and writes from/to different files. I think a better solution would be to replace the file system by a SQLite database. How hard is it to migrate ...

热门标签