• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
  • salvin francis
  • Frits Walraven
  • Piet Souris

Simple Question about Log4J

Ranch Hand
Posts: 264
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been given the task of being a maintenance programmer and so I've inherited a large amount of code. I'm fairly certain I know the answer to this question, but the original programmers are not here to ask so...

log is an instance Logger. Is there any point in the enclosing if statement? I'm fairly certain the obvious answer is no, but it seems so obvious to me that I'm wondering if I'm missing something.

Removing the surrounding if statement shouldn't have any effect on the program? (other than trimming size and possibly speeding up the application depending on how often this code is executed, unless the javac removes the extra check during optimization anyway anyhow).
Posts: 10445
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This sort of code is used to avoid unnecessary memory being allocated on heap. Consider the following String that is used in the debug message:

log.debug( toString() + " : " + someMessage.toString() );

As you might be knowing, when the '+' operator is used on String objects as in:

toString() + " : " + someMessage.toString()

the resultant String that gets created will be allocated memory on the heap(dynamically at run-time).

Now consider that you *dont* have the check:

if ( log.isDebugEnabled() )

For the statement:

log.debug( toString() + " : " + someMessage.toString() );

to be executed, memory will be allocated on the heap for the resultant string which is passed as a parameter to the debug method. Then later on internally in the debug method there will be a check of whether debug level is enabled for that particular package. If its not enabled, then the memory allocated on the heap will be wasted. To avoid this, the check is made(by using the isDebugEnabled() method) even *before* the String object is created out of the '+' operator on the heap.

This is just a way of saving heap memory
[ July 31, 2006: Message edited by: jaikiran pai ]
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The removal of the log statement will not effect the functionality in any case

The only difference will be of the logging of the statements and somewhat of speed.

The Log4j has the different logging levels. like debug, info, fatal, error
During the development process, a dev might keep the Logging level as debug as a precautionary measure
to debug the program.
For this, the logging level can be set to DEBUG.
The logger will chk for the DEBUG enabled part and process the if statement accordingly.

However, when the code is deployed , the end user may not be interested in the full debug statements.
The level then might be set to INFO or fatal in that case.
For those scenarios, the above mentioned debug statement will be skipped.

So, this can be pretty much useful for the debug purpose without changing much in the code.
The logger level set in the log4j properties file will decide the process.

Hope, something useful conveyed for the above.

The only cure for that is hours of television radiation. And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic