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.
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.
Do you mean compiling with the debug option? http://stackoverflow.com/questions/218033/is-there-a-performance-diff-between-javac-debug-on-and-off
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.
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.
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.