Investigate possible use of Java System Logger over Commons Logging API

[mdeinum]

In #19081 (about 5 years ago) a discussion and decision was made on how to approach logging for Spring Framework 5.0.

As the baseline of Spring Framework 6 has been lifted to Java 17 it might be worthwhile to investigate the custom log setup and use the default logging API (System.getLogger) provided by the JDK. Or at least have an explicit decision on the usage of that API for future reference.

I know that SLF4J (and thus Logback) and Log4j2 have integration for it.

[vpavic]

I was under impression that the System.Logger was intended for JDK's own internal usage. The JEP 264 has the following among its non-goals:

It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage.

[ciscoo]

The summary also has this bit:

A library or application can provide an implementation of this service in order to route platform log messages to the logging framework of its choice

As far as I know, Spring projects themselves do not require advance logging capabilities, so the bare minimum logging capabilities that is for the JDK's own needs could largely satisfy Spring's uses.

In addition, dropping spring-jcl in favor of System.getLogger may alleviate some issues with spring-jcl as noted in a Reddit thread:

It still adds more bloat to each JAR you make though, even if it is tiny.

Relies on classpath ordering.

Hijacks the package/module of a different project, this more or less guarantees it will never work with a module system be it JPMS or OSGi

Regardless, I think a discussion on logging for the next generation of Spring is warranted since the new baseline will be Java 17.

[mdeinum]

Regardless, I think a discussion on logging for the next generation of Spring is warranted since the new baseline will be Java 17.

Which is the main reason for me to open this issue. I can live with either decision To System.Logger or not to System.Logger. If there is a decision from the Spring team we can use this ticket as reference.

I was under impression that the System.Logger was intended for JDK's own internal usage. The JEP 264 has the following among its non-goals:

It is not a goal to define a general-purpose interface for logging. The service interface contains only the minimal set of methods that the JDK needs for its own usage.

Although I tentatively agree, the API provided by the System.Logger is more or less the same as with Commons Logging and provides methods for lazy log message creation, which could lead to simpler code instead of guarding it with logging checks.

[vpavic]

Any hints maybe whether the team will consider this in not too distant future? Thanks.

[ciscoo]

Was looking at issues on Boot and remembered this one.

Wondering if those issues could have been avoided entirely if spring-jcl was replaced/superseded.

• Log a warning when commons-logging is in the classpath #30575
• Exclude commons-logging from managed dependencies spring-boot#37890

[jhoeller]

At this point, we intend to go with Commons Logging 1.3 as suggested by #32459 - keeping all existing logger API usage intact, just dropping the spring-jcl artifact.