Do you find java.util.logging sufficient?

Question

question from:https://stackoverflow.com/questions/607863/do-you-find-java-util-logging-sufficient

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. ;)