One of the challenges in any programming environment is to be able to debug the code effectively. While developing Java applications, you can use breakpoints in tools such as JDeveloper, print to standard output to observe the execution of the program, or look at the stack trace when the program throws an exception.
Suppose an application that's running in unattended mode on the server is not behaving properly. Everything seems to work fine in your development and test environment; yet, in the production environment, something seems not to be "working" correctly. (How often have you heard that from one of your customers?)
If you decide to print to standard output or to a log file, as an application developer you need to worry about commenting out the code in production to reduce the overhead associated with the calls.
Another approach is to define a Boolean variable, say debug, and if the value of the variable is true, the application prints a whole set of debug messages. You compile by switching the flag one way or the other to get the necessary behavior. This is computationally expensive in addition to being cumbersome.
With the logging API, however, you don't need to recompile your program every time you want to enable debugging, and you can set different levels for logging messages without incurring too much computational expense. You can even specify the kind of messages you want to log. Using a configuration file, you can change the runtime level of the logging information. This information can be written to a file, a screen console, a socket, a database, or any combination. It can be very detailed or very sparse, based on the level set at runtime, and may differ for various consumers of the information. For detailed analysis, examine the log file to discover when and where a problem occurs.