Hi 单红宇,
On 19.12.2025 09:57, 单红宇 wrote:
> I'm writing to propose migrating the Commons JEXL project from Apache Commons
> Logging
> to SLF4J as the default logging facade.
Thanks for taking the time to write up this proposal.
Similar suggestions have come up periodically over the years (although I
could not quickly locate a previous thread: pointers are welcome). The
short answer remains the same: it is *very unlikely* that Apache Commons
projects will migrate to SLF4J as their logging API.
There are several reasons for this position.
First, Commons Logging is generally sufficient for Commons libraries.
Commons projects are foundational libraries; they tend to log sparingly
because meaningful diagnostic context usually exists at higher layers of
an application. In practice, errors and failures are communicated via
exceptions rather than logging.
Second, there is a significant overlap between the Commons PMC and the
Apache Logging Services PMC. If Commons projects were to reconsider
their logging API at some point, the more natural direction would be
toward the Log4j API [1], not SLF4J. The Log4j API is newer (initially
released in 2014 rather than 2004), actively evolved, and includes
capabilities such as structured logging that SLF4J has only added quite
recently.
Third, on a more personal note, I have some concerns regarding the
long-term sustainability and governance of SLF4J. It remains a
single-maintainer project, with no publicly documented succession plan.
This point is also highlighted in the recent Logback security audit [2]:
“Currently, the main owner of the project holds all access rights”
“Open-source organizations are advised to back up the sole developer
of critical components, by increasing the number of trusted
individuals responsible for reviewing code modifications.”
Together with Christian and Volkan, we previously attempted to address
this situation by proposing a community-governed logging facade based on
SLF4J (Jakarta Logging [3]). The broader ecosystem, however, preferred
to maintain the status quo.
If there is ever a change in this area, it would more likely happen as
part of a hypothetical Commons Logging 2.0, allowing us to selectively
adopt the best features of existing logging APIs rather than switching
wholesale to another facade.
The analysis included in your proposal appears largely AI-generated and
reflects a number of common, but inaccurate, assumptions. For clarity,
I’ll address a few of them explicitly.
> Modern Ecosystem Alignment: Most contemporary Java frameworks
> (Spring Boot, Hibernate, etc.) have migrated to or recommend SLF4J
> as their logging facade.
This is incorrect.
- Spring Framework / Spring Boot use Commons Logging (via spring-jcl),
not SLF4J directly.
- Hibernate uses JBoss Logging, not SLF4J directly.
In both cases, SLF4J is used as a runtime backend, not as the API these
frameworks depend on.
> Flexible Backend Support: SLF4J supports multiple logging
> implementations (Logback, Log4j2, JDK logging) without requiring
> code changes.
This is not unique to SLF4J. Commons Logging, JBoss Logging, and the
Log4j API all provide the same capability.
It is also worth clarifying how the ecosystem actually looks today.
Each of the three major logging implementations has its own native API:
- Logback -> SLF4J
- Log4j 2 Core -> Log4j API
(A common misconception: Log4j 2 Core does not implement SLF4J [4])
- JUL -> no API/implementation split
Each facade provides bridges to these native APIs:
- Commons Logging (since 1.3.0) includes native bridges to all three.
- JBoss Logging follows a similar approach.
- Log4j API requires external bridges to SLF4J (log4j-to-slf4j) and JUL
(log4j-to-jul), both maintained within Apache Logging Services.
- SLF4J provides its own JUL binding (slf4j-jdk14), while the Log4j
bridge (log4j-slf4j2-impl) is maintained by Apache Logging Services.
> Better API Design: SLF4J provides a cleaner API with no checked
> exceptions and supports MDC (Mapped Diagnostic Context) for advanced
> logging scenarios.
No mainstream Java logging API uses checked exceptions, so this is a
non-argument.
As for MDC: it was a useful abstraction 20 years ago. In modern Java,
especially with widespread concurrency and the introduction of virtual
threads, MDC increasingly represents a problem rather than a clear
advantage.
*TL;DR*: While SLF4J *is* a popular and widely deployed logging facade,
the arguments presented do not provide sufficient justification for
migrating any Commons project away from Commons Logging.
Regards,
Piotr
[1] https://logging.apache.org/log4j/2.x/manual/api.html
[2]
https://ostif.org/wp-content/uploads/2025/02/LOG-01-Logback-Audit-Report-Public-RC1.1.pdf
[3] https://projects.eclipse.org/proposals/jakarta-logging
[4] https://logging.apache.org/log4j/2.x/manual/implementation.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
