Java Logging Framework

This difference is mainly between built-in JVM solutions versus pure external libraries.

For Platform Logging API and Service and Java Util Logging, you need to be able to put the implementation you use at JVM level (either a system property or a SPI in the JVM classpath, not a subclassloader).

For log4j2 and slf4j you need to put the implementation with the classloader loading the API…​ok let me explain this one. If you have a flat classpath you are back to the previous case, nothing crazy. If you are in OSGi, one bundle will provide the API and, until you use a specific mechanism like a whiteboard, this bundle will load the implementation so this bundle must be able to find your implementation. In a JavaEE/JakartaEE container you have the JVM classpath then often a container classloader and finally your application classloader(s) so depending which classloader loads the API you use, you can put the implementation in the same loader or not.

Let’s dig in this last case which is quite representative of this criteria: if the container provides SLF4J-API and does not let the application override it - it is not only about children fist since SLF4J also uses resource directly and not only class loading, then you will use the implementation - binding for SLF4J - of you container even if you put another one in your war. Now the opposite is true as well: if you want to put in your container SLF4J-API + logback to configure everything at container level, then you can’t if your container enables the application to override it and not configure this behavior.

This represents this first criteria: do you want to control your logs from:

If you want to use JLink, you must have a compatible library, ie with a (working) module-info. All the mentioned libraries have it but slf4j integration with JPMS (module platform of Java - JLink to make it short) is not yet mainstream and well integrated. Log4j2 has module-info but part of it can not work - dependencies mainly - so no guarantee until you test or just use log4j2 itself.

Indeed the JVM solutions work with JLink.

For GraalVM native-image - the binary enabling to convert Java bytecode to a native binary to get a lighter and faster application, it is the same kind of story. Integrating with native-image is quite some work and the design of Log4j2 kills it - a lot of it is static or instructions are not GraalVM friendly so if you want to use it you must do a lot of custom codes - substitutions. Logback has some working setup but it is based on workarounds as well. JUL is not perfect too since by default it is not reconfigurable but some custom log managers are - like Yupiik Logging.

So if you intend to do a custom packaging or native binary (for docker for ex ;)) of your application, JUL clearly wins the game.

There are two solutions in the JVM? Seriously?

Yes and actually in Log4j/logback you can find 2 as well if you look well.

Long story short, the issue is: how to log anything while you are setting up the logging?

This is what the platform API solves.

Indeed, some applications can use it - I’m thinking to javaagent which shouldn’t trigger JUL initialization too early for example - and technically speaking any application can but it is not designed as a full logging library so you will miss concepts and fluentness in the API itself.

The conclusion is - in the JVM context: if you write a super light bootstrap library for Java then use the Platform Logging API and Service, else use JUL.

A common need in the logging area is to keep a low overhead. Typically if I do:

I will evaluate the concatenation and create an overhead I don’t need if the debug level is not kept by the logger chain (output/consumers).

A common workaround is to wrap it in a isLoggeable kind of call:

But it makes the code more verbose.

To solve that, frameworks created some alternatives. Historical framework use interpolations (SLF4J, Log4j2):

This will pass the pattern + values and evaluate it lazily if the message is logged.

JUL provided, thanks to Java 8 new API, a very interesting alternative using Supplier:

Using a lazy provider of the message this makes the code:

So here JUL wins IMHO.

With all its appenders, Log4j2 is likely the most complete framework in terms of integration. You can compare to Logback ones if you want.

JUL has mainly only stderr/stdout, file and socket outputs by defaults but it can be complemented by some custom or libraries like Yupiik Logging to get more power.

Just looking like that you will make Log4j2 winning but I’d like to emphasise the fact you should only care about what you need so if you don’t care about Kafka appender/handler, then don’t consider it as a criteria. Personally I only care about container case so (rotating) file + stdout/stderr outputs are the only ones I want so all are equivalent - using Yupiik Logging for JUL case.

In a docker environment we mainly want to be able to log as JSON on stdout/stderr - small bonus there being to be able to log errors on stderr and other levels on stdout.

All libraries support that case but the stack is not always the same.

Log4j2 has some native JSON encoding (plain string manipulation) but it does not make the output very JSON friendly you so end up using the jackson integration quite quickly.

Logback relies on a contrib using jackson as well (it is an external integration).

JUL does not have anything built-in but Yupiik Logging brings a JSON-B (javax and jakarta) integration to get it.

Regarding the stderr/stdout point, each output/appender/handler is generally linked to a single stream but Yupiik Logging enables to redirect the log records depending the level on stdout or stderr.

So overall I think this criteria is met by all libraries.

MDC (or NDC to be more advanced) are a way to pass some context to the formatter/encoder to let some additional data be used.

Concretely it behaves - and is often implemented as - a ThreadLocal passed to the formatter to let you use a pattern extracting some data from this local "map".

JUL is the only one without this concept but it is trivial to use a custom formatter - potentially wrapping an existing formatter to reuse what exists - to add this capability.

So for this criteria Log4j2 and Logback are a bit better but I would not weight a lot this criteria but more use it as a decision one if everything else is equal.

The size of any library s important at some point - keep in mind docker images are downloaded on pods or dev machines for example.

Log4j2 is about 2M, logback is about 500k and JUL is 0 since in the JVM (another cached layer of you docker image and there anyway even if not used by your application).

So here JUL wins even if 2M is ok-ish.

Is the solution you pick a built-in solution or not is important, and indeed only JUL meets the fact it is built in.

For your application it is not a big criteria but do you write a dependency free application? Likely not.

As far as you have some library doing some logging, you must ensure all your application logging is unified and go to the same location.

Concretely if you pick logback you must ensure that JUL logs go to SLF4j, that log4j2 logs go to SLF4j, that JBoss Logging (another facade) goes to SLF4j, etc…​

There are several cases there to decide.

Logging overhead must stay acceptable. Once we said that we said nothing :). The overall point is that you shouldn’t pay as much as your business logic for logging, we often reference ⇐ 5% in terms of ratio even if it is not a strict limit.

When logging to stdout/stderr or their virtual equivalent (in docker it is not the tty of your machine so it is a bit faster) the performances are close and mainly depends the formatters/encoders you are using. But when logging to a file, Log4j2 and Logback are generally faster but for JUL you can implement you own handler or use your container one (Apache TomEE provides one which has rotation support and is quite fast, Apache Tomcat also provides one which is not bad with rotation support). Worse case for JUL you can use a library like Yupiik Logging which has a good file handler/appender which can replace the one of the JVM.

Sometimes we get the reference of asynchonous loggers or appenders. Here Log4j2 is likely the best but you must also ensure to understand what it means:

This last point is very very tempting but it also means you will prevent some application code execution from application unrelated code so the application behavior can become less stable/predictable in some cases…​.and don’t even think to reduce the priority of these threads until you don’t care of the logs which means you should just not log if so ;).

So personally I think that asynchronous loggers are not a killer feature but more a workaround for wrongly designed handlers. Concretely there are cases it is interesting:

But this is an implementation of the appender/handler, not a feature moved to loggers.

I’ll not mention a winner there because, in my opinion, all are fine in synchronous mode while the configuration is done properly - ie don’t use default JUL file handler for example. Log4j2 and logback have, indeed, interesting asynchronous wrapper but it is quite trivial to do for JUL too in < 100 LoC and they generally tend to show some issue elsewhere but there are rare case it can be a criteria (clearly not for web application or batches but more for some daemon).