Install JUL-to-SLF4J bridge to route java.util.logging through Maven logging

[cstamas]

Affected version

master

Bug description

See apache/maven-resolver#1772
That library uses JUL logging, and log line ends up on stderr. Why?

[kwin]

I think logging to stderr is the default of JUL: https://docs.oracle.com/en/java/javase/25/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA__DEFAULTCONFIGURATION-4D023EDA

[desruisseaux]

I confirm, by default java.util.logging logs to stderr, but this is configurable. I believe that the reason for stderr is because in a command-line application, stdout may be used for an application output intended to be parsed by other applications. If logs were also sent to stdout, they would be mixed with the application output.

Example: imagine a sort application taking lines from stdin and sending sorted lines to stdout. We do not want the log records to appear in the middle of sorted lines. Since there is no stdlog, the less bad choice seems to be stderr. That way, we can redirect the application output and the logs in two different files on the command-line.

[slawekjaranowski]

There is a bridge JUL -> slf4j ...
https://www.slf4j.org/legacy.html#jul-to-slf4j

[kwin]

I don't think there is an actual issue within Maven to solve here. Can we close this one as invalid @cstamas?

[desruisseaux]

Maybe one thing that Maven could do is that, by reading the link provided by Tamas, Maven seems to consider everything printed on stderr as warning. Maybe it should be relaxed, but it may not be easy to differentiate logs from real errors.

[cstamas]

IMO maybe we should install JUL to SLF4J Bridge? After all, we do want all logging to happen via maven/slf4j logging, and not have multiple logging systems in place?

[desruisseaux]

Installing JUL to SLF4J Bridge may be the easiest short term solution. In longer term, I would question if we really need SL4FJ and whether we could use JUL instead. One of my long term hope is to make Maven faster to start (I see the existence of Maven daemon as a problem symptom rather than a feature), and one way to achieve that would be to reduce the number of dependencies.

[kwin]

The use case for apache/maven-resolver#1772 is not really about JUL but more about https://openjdk.org/jeps/264. I created #11684 to track that.

[kwin]

https://www.slf4j.org/legacy.html#jul-to-slf4j has severe performance issues

If you are concerned about application performance, then use of SLF4JBridgeHandler is appropriate only if any one of the following two conditions is true:

1. few j.u.l. logging statements are in play
2. LevelChangePropagator has been installed

LevelChangePropagator is imho only part of Logback and we don't know how many JUL logs are issued during a Maven run

[cstamas]

I think PR #11685 solves this issue (to have methanol log to maven logging backend)

[gnodet]

Libraries using java.util.logging (e.g. maven-resolver internals) currently bypass SLF4J and dump directly to stderr, producing confusing output mixed with Maven logs.

Proposal for 4.0.0-rc-6: Install the jul-to-slf4j bridge (org.slf4j:jul-to-slf4j) at Maven startup. This routes all JUL loggers through SLF4J and Maven's logging infrastructure, so JUL output respects Maven's log level configuration and formatting.

The System.Logger (JEP 264) approach mentioned in #11684 can be revisited for 4.1.0 as a more comprehensive solution.