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.
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.
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 ...
Check this, List<String> list = new ArrayList<String>(); for (int i = 0; i < 10000; i++) { String value = (""+UUID.randomUUID().getLeastSignificantBits()).substring(3, ...
I am in the middle of solving a problem where I think it s best suited for a decorator and a state pattern. The high level setting is something like a sandwich maker and dispenser, where I have a set ...
I have been trying to execute a MS SQL Server stored procedure via JDBC today and have been unsuccessful thus far. The stored procedure has 1 input and 1 output parameter. With every combination I ...
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 ...
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 ...
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....
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 ...
