Do you find java.util.logging sufficient? [closed]

Question

Per the title, do you find the default Java logging framework sufficient for your needs?

Do you use alternative logging services such as log4j or others? If so, why? I'd like to hear any advice you have regarding logging requirements in different types of projects, and when integrating frameworks is actually necessary and/or useful.

Answer 1

java.util.logging (jul) was unnecessary from the beginning. Just ignore it.

jul in itself has the following downsides:

• At the time that jul was introduced in Java 1.4 there was already a well established logging framework in wide use: LOG4J
• the predefined log levels are: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST. I won't tell you what I personally think about those predefined levels to keep this answer semi-objective.
• Additional levels can be defined. jul supports up to 4G different log levels which is slightly overkill, IMHO. Less is sometimes more.

• The most important point: if you dare to define your own log level you are likely to run into a memory leak issue!
  Feel free to read about this effect here:

  • Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception
  • How to fix the dreaded "java.lang.OutOfMemoryError: PermGen space" exception (classloader leaks)

  It's a pretty interesting read even if you are not planning to use custom levels, btw, since the problem is a wide-spread one that doesn't just apply to jul at all.

• it resides in the java.* namespace so the implementation can't be exchanged at runtime. This effectively prevents bridging it to SLF4J the same way its possible in case of commons.logging and LOG4J. The way bridging is done for jul has a performance impact. This makes jul the most inflexible logging framework out there.
• By introducing jul, Sun implicitly defined it to be the "standard java logging framework". This led to the common misconception that a "good Java citizen" should use jul in their libraries or applications.
  The opposite is the case.
  If you use either commons.logging or LOG4j you'll be able to exchange the actually used logging framework, if you ever need to, by bridging to SLF4J. This means that libraries using either commons.logging, LOG4J or SLF4J can all log to the same logging target, e.g. file.

I'd personally suggest to use the SLF4J+Logback combo for all logging purposes. Both projects are coordinated by Ceki Gülcü, the guy behind LOG4J.
SLF4J is a worthy (but unofficial since it's not from the same group) successor of commons.logging. It's less problematic than CL because it statically resolves the actually used logging backend. Additionally, it has a richer API than CL.
Logback, on the other hand, is the (un)official successor of LOG4J. It implements SLF4J natively so there's no overhead caused by any wrapper.

Now you may downvote me if you still think I deserve it. ;)

Answer 2

Logging Dependencies with Third Party Libraries

Java JDK logging in most cases is not insufficient by itself. However, if you have a large project that uses multiple open-source third party libraries, you will quickly discover that many of them have disparate logging dependencies.

It is in these cases where the need to abstract your logging API from your logging implementation become important. I recommend using slf4j or logback (uses the slf4j API) as your API and if you want to stick with Java JDK logging, you still can! Slf4j can output to many different logger implementations with no problems.

A concrete example of its usefulness happened during a recent project: we needed to use third-party libs that needed log4j, but we did not want to run two logging frameworks side by side, so we used the slf4j log4j api wrapper libs and the problem was solved.

In summary, Java JDK logging is fine, but a standardized API that is used in my third party libraries will save you time in the long run. Just try to imagine refactoring every logging statement!

Answer 3

SLF4J is the new kid. I've done a little work with it and it's pretty nice. It's main advantage is parametrized logging, which means you do this:

logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

Rather than this:

logger.debug("The new entry is " + entry + ". It replaces " + oldEntry + ".");

And all that string manipulation is done only if the statement is actually logged. Looks cleaner too.

It should be noted that SLF4J is a wrapper like commons-logging, though it claims to be less prone to commons-logging's classloader problems.