Hi all,
For starters: it's not really a pressing matter ATM, but it may
become of relevance if we want to strive for a production-release.
The matter is somewhat related to the distinction between developer-
and user-directed logging.
It concerns the numerous log.debug() and log.trace() messages
scattered around. Just recently, I was reminded of a little Java
trick that emulates C's conditional compilation, which inspired me to
pop this question here.
As you are most likely well aware, every log.debug() generates
bytecode at compile-time, which leads to compiled classes being
unnecessarily large for general usage. In Java, there exists this
little trick to define a final debug() method:
final void debug(String msg) {
if (DEBUG) {
log.debug(msg);
}
}
The DEBUG boolean constant being defined in a central, easily
accessible place.
If subsequently, all log.debug() calls are replaced by mere debug(),
and one sets DEBUG to false, then the result at compile-time is that:
- there is no bytecode generated for the debug() methods (empty body)
- since the method is final, and it has an empty body, the compiler
can optimize further and no bytecode will be generated for any call
to it. Meaning also: possible string literals in the message do not
take up space in the internalized string-table, which in turn would
be beneficial for eventual runtime-calls to String.intern() (smaller
table => decreased lookup-time)
In order to switch on dev-directed debugging code, one would only
need to change the value of the DEBUG constant and rebuild from the
very same codebase, so the related code gets compiled in.
Questions:
1) Is there IYO still a benefit to such an approach? After all, if I
remember correctly, this trick is quite old, so may bear only little
relevance to current JVM's? The class-size argument may still make it
worthwhile, nonetheless. (FOP is already a reasonably large package
in itself, leaving out all the debug-related code...)
If yes/pro:
2a) How should we go about that?
* Location of the centralized DEBUG constant?
(hardcode it? make it settable as a build property?)
* One debug()/trace() per class having a log instance member?
(could lead to conflicts: inability to override final method?)
If no/contra:
2b) Any alternatives?
Cheers,
Andreas
