> Andrew Scherpbier wrote:
>
> Using compile time constants to turn diagnostics on and off is something
> of a hot point for me - it can make it very difficult to diagnose
> problems in typical production environments in the companies I work with
> (rebuilding the app. server to get diagnostics is a no-happen)
I have the same problem with compile-time constants. So I use load-time constants! I
think it works great.
To explain: I have a class Foo (names have been changed etc.) with a public static
final boolean debug. It is set to true or false in the static initializer, ie. at
load-time, by looking up a System property or something. Note that is final, meaning
that a good JIT can remove dead code after loading. (Or at least hotspot does, from
what I can tell after some profiling.)
Foo has lots of static methods that delegate to my logger object. All these static
methods have an outer if statement around the entire method body, that checks the
debug value before processing the input. Ie. I have:
public static void println(String msg) {
if (debug) {
....
}
}
Then, to log, I say:
Foo.println(my.expensive(statement));
Since the println method, being static, is entirely dependent on Foo.debug, it will
not called if it is false. However, the argument is still expensive to create, it
_will_ still be executed, and I _don't_ want to write this all the time:
if (Foo.debug) Foo.println(...);
This would obliterate the entire call nicely, but it's not fun, is it, and I'm bound
to miss a few. But, since all the log statements I want compiled away are static
calls to Foo (make it abstract, is my advice), I can simply add an ant task to my
production build target that begins like:
<replace token="Foo.print" value="if (Foo.debug) Foo.print"
... before the javac task. After that, I can still take a lump of in-production
quality byte code, and start it up with the -Dfoo=true property, upon which all my
logging statements are turned back on.
Would this address any of your concerns?
Kjetil
______________________________________________________________________
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66&thread=5895
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
