Switch to SLF4J for logging.

[garretwilson]

Moneta seems to be using JUL for logging; it should switch to SLF4J.

Simple Logging Facade for Java (SLF4J) has long been the de-facto standard logging facade for Java. While java.utl.logging (JUL) was an interesting idea, it failed to achieve anywhere near the acceptance as Log4j and Logback, and the result was just more splintering and confusion in the Java logging space. SLF4J provides a common logging interface and allows the ultimate logging implementation to be decided by end application, not by the dependency producing the logs.

In other words, just as Java Money is divided into the javax.money:money-api API and a certain implementation org.javamoney:moneta, modern logging in Java should be using SLF4J as the API and allowing the end application to choose the implementation, whether it be Logback, Log4J, or even JUL. Moneta should not be binding itself to a single implementation (here JUL).

JUL in particular is problematic for logging. Although SLF4J provides various adapter for bridging legacy logging APIs, JUL provides additional issues beyond those of the other logging systems:

Contrary to other bridging modules, namely jcl-over-slf4j and log4j-over-slf4j, which reimplement JCL and respectively log4j, the jul-to-slf4j module does not reimplement the java.util.logging because packages under the java.* namespace cannot be replaced. Instead, jul-to-slf4j translates LogRecord objects into their SLF4J equivalent. Please note this translation process incurs the cost of constructing a LogRecord instance regardless of whether the SLF4J logger is disabled for the given level or nor. Consequently, j.u.l. to SLF4J translation can seriously increase the cost of disabled logging statements (60-fold or 6000%) and measurably impact the performance of enabled log statements (20% overall increase). (emphasis in original)

Additionally, if I want Moneta logging routed to SLF4J (allowing me to then route logging to e.g. Logback or Log4j using the standard SLF4J metchanisms), I can't just add org.slf4j:jul-to-slf4j as a dependency (as I would for the other logging bridges); I must also add the following (see the SLF4JBridgeHandler docs for more details):

//bridge JUL to SLF4J for Moneta logging
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();

In short, SLF4J has long been the de-facto standard for logging in the Jogging community, and provides a common, well-known API with flexible configuration for routing to the logging framework of choice. Moneta should switch to SLF4J logging and let the end user decide which implementation to use. (In fact Moneta should not even ship with a logging implementation; it should merely use the SLF4J logging API.)

I am potentially available to contribute this work. Please let me know that this work would be approved, and I will investigate further regarding the feasibility and time frame.

[keilw]

I appreciate your offer to help, but the logging world is far more fragmented than just SLF4J. I know first-hand when people tried in the JCP and recently in Jakarta EE to establish a common logging spec. So far without success.

On a different note people asked, why we introduced another library with OkHttp to fix problems the old JDK URL connectors caused with currency conversion. From 1.5 on we seriously consider switching to the JDK HttpClient, for the time being and prior to a Java 11 minimum OkHttp has to stay. So we would also prefer a built-in solution like JUL or the new System.Logger from 1.5 onward.

See this Micronaut issue other projects also move from SLF4J to this abstraction layer, so we would also prefer it. The master branch is already for Moneta 1.5, so happy for help, if you would like to contribute a System.Logger customization along the lines of the Baeldung example, you can even use SLF4J, but don't call it directly, it should be a delegate from the Java Platform Logging API.

[garretwilson]

… if you would like to contribute a System.Logger customization along the lines of the Baeldung example …

Although I'm familiar with JUL and very familiar with most of the other logging packages, somehow I missed System.Logger. From first glance it at least allows pluggable logging, which can be bridged to SLF4J or JUL via just by adding a dependency. This in itself would be a benefit over JUL, because as I mentioned above bridging JUL requires code changes. So thanks for the pointer; I'll eagerly go learn more about System.Logger and make an evaluation.