I believe the Java Language Spec makes specific requirements on the
order of evaluation of static finals to facilitate this kind of usage. In
the past I have
gone so far as to compile test programs and disassemble the byte code
and on every JVM I have ever tried, code wrapped in if statements that
evaluate a static final boolean doesn't even generate byte code for the
contents
of the block if the boolean is false. So there is no performance or size
penalty.
The real problem with this sort of thing is more subtle. How do you control
the
value of the boolean? Should there be a single public static final in a
class that
is referred to everywhere? More likely one wants to turn on and off
debugging in
a single class, or package, or globally, depending on what is being tested.
Having to do search and replace on scattered variables is annoying at best.
How is the make system coerced into doing debug builds vs production
builds in a simple manner, in the absence of a preprocessor?
These are specifically the sort of problems the new java.util.logging
package in
JDK 1.4 is addressing. I believe the philosophy there is to always leave the
code in place, be liberal in writing tracing log calls and assume that
integer comparisons
to decide whether to execute a particular logging call are so cheap that
there is essentially
no performance penalty at runtime. I am not as familiar with log4j.
Cheers - Mark
At 08:56 AM 7/19/2001, Craig R. McClanahan wrote:
>On Wed, 18 Jul 2001, Justin Erenkrantz wrote:
>
> > On Thu, Jul 19, 2001 at 12:16:27AM +0100, Pier P. Fumagalli wrote:
> > > Checking out the source code, I see a lot of // (commented out lines)
> when
> > > debug() is supposed to be called...
> > > Can't we have a global constant boolean called DEBUG and replace the
> // with
> > > if (DEBUG), so that we can simply compile in and out the debugging
> > > information without touching the sources?
> > >
> > > Check out org.apache.catalina.connector.warp.Constants and
> WarpLogger... Old
> > > trick we used in JServ. :)
> >
> > I *believe* most Java compilers do not have constant conditional
> > optimizations (they certainly could, but I don't think they did last
> > time I checked). Without that optimization, you must check that
> > value each time you execute the statement. That might hurt. -- justin
> >
> >
>
>In trivial experiments a long while back, I seem to recall that this trick
>worked if your constant was "static final". But I haven't looked lately.
>
>There are also some cases where you want to be able to set the debug level
>at runtime, without having to recompile. In such cases, I typically am
>real liberal about debug statements when first creating a module, and then
>comment them out (versus removing them) in high-frequency-of-use portions
>of the code. That way, you've got ready-made debug code to uncomment if
>you run into problems later.
>
>
>Craig
