Deprecate the Log4j Scala API

[ppkarwasz]

In the Scala ecosystem, the most widely used logging API is Lightbend’s Scala Logging. It is a community-driven project with strong adoption and integrates naturally with Scala features, notably macros that transform string interpolation into parameterized logging at compile time.

Given this, it may be worth reconsidering the role of the Log4j Scala API. Instead of maintaining a separate Scala-specific API within Log4j, we could deprecate the Log4j Scala API and focus on contributing missing functionality to Scala Logging.

Although Scala Logging is currently tied to SLF4J, its design could be extended to support additional backends without breaking changes, similar to Commons Logging. Introducing a native Log4j API backend would allow Scala users to benefit from Log4j API-specific features, such as capturing log statement locations at compile time via LogBuilder#withLocation.

What do you think about:

1. Deprecate the Log4j Scala API.
2. Engage with the Scala Logging maintainers to explore adding a native Log4j API backend.

[SpaceLeam]

+1 from me.

I recently spent time debugging this API (related to the crash fix I'm currently preparing), and I agree that maintaining parity with the Core safety guarantees seems unnecessarily difficult here. The disconnect between the Java implementation and the Scala wrapper creates edge cases that are hard to catch and maintain.

In fact, while auditing the code for the traceEntry fix, I noticed similar "eager evaluation" risks in other parts of the API where the wrapper deviates from the Core's fail-safe logic. Patching these architectural mismatches one by one feels like a whack-a-mole game.

Moving to a native backend for Scala Logging sounds like a much more stable future for users.

[vy]

+1

The original authors of the project (@jvz and @mikaelstaldal) has moved on. I am the only active maintainer, yet I don't use the library myself, I just maintain it due to feeling responsible as an Apache Logging Services (Log4cxx, Log4j, Log4net) PMC member. I put significant effort into making the build and development experience as smooth as possible, revamping the CI and the website, updating the dependencies, helping with PRs and bug reports, etc. @pjfanning — who is a PMC member of Apache Fory, Pekko, and POI — supported me a lot during this pursuit, and it was him who first brought up the suggestion that Log4j Scala API should be retired. It succeeded in neither getting attraction, nor seeing usage. Plus, Scala logging ecosystem has evolved significantly since 2016, the year Log4j Scala API was introduced. I want to sunset the project and spend my time on more pressing F/OSS issues.

[mikaelstaldal]

I would not object to deprecate/sunseting it.

[vy]

Backlinks:

• the VOTE thread
• r/scala post

[hygt]

Hello. I believe I've seen my share of Scala codebases in the past 10+ years, across multiple employers and most of the popular stacks or frameworks (Play, Akka, Spark, Flink, functional ecosystems, ... basically anything not too exotic)

First, log4j2 is rarely used as the logging backend. Many projects tend to default to logback. People who look into logging more seriously would pick a more idiomatic and native Scala backend as we have pretty awesome ones. Two exceptions spring to mind:

• sbt, which defines its own logging interface
• Spark and Flink, they don't use the Scala API

As for log4j-api-scala it seems the only reverse dependency is Scalaxb. I'm not sure to understand why exactly, maybe it's worth asking @eed3si9n ?

You're absolutely right about the widespread usage of macro-based frontends. And Lightbend's Scala logging isn't the only one.

[eed3si9n]

Why use log4j2 or why use log4j-api-scala? I think scalaxb was on log4j 1.x until Feb 2025, then I got a pull request from @urwithsumit as eed3si9n/scalaxb#681 to bump to log4j2. I thought it was reasonable to bump from log4j 1.x to log4j2, and didn't think too much about the fact that it uses the Scala API. I'd be happy to drop its use of Scala API, or switch to another logger.

As for sbt 1.x, I did actually use log4j2 when sbt 1.0 was released, and had high hopes for its much-touted performance, but a contributor who was more performance-minded discovered that it was actually being a bottleneck for sbt's usage, and we decided to go back to rolling our own logger instead.

[hygt]

I meant the usage in Scalaxb, thank you for the clarification.
I think you can just remove the dependency as the project depends on log4j-core anyway.
That's probably not a good thing by the way. I assume Scalaxb is meant to always (or mostly) run in the build tool context? I believe sending logs to SLF4J should cover both Maven and sbt builds in this case.
I can do some experimenting and open a PR if you're interested.

[eed3si9n]

I believe sending logs to SLF4J should cover both Maven and sbt builds in this case. I can do some experimenting and open a PR if you're interested.

I prefer to pick a concrete logger like log4j2, rather than letting classpath decide this. PRs are always welcome tho.

[pjfanning]

+1 I've never personally seen this lib being used in practice. If people use it, they have a chance to say so here. It doesn't seem worthwhile to maintain this lib if it isn't widely used.

[gaeljw]

TBH I just learned about it today thanks to your post on Reddit.

I've never encountered it in a Scala codebase (7+ years doing Scala). Most of the time, I've seen just regular use of SLF4J or log4j2 Java APIs, with also the Play Framework's wrapper around SLF4J.

IMHO it's a fair move to retire the log4j2 API. And if some folks really have the need for log4j2 backend with Scala features, why not reach out to include it in scala-logging but I, personally, don't have a need for it.

[pjfanning]

Crucially, there is a bridge implementation for slf4j to log4j - https://www.slf4j.org/legacy.html and https://logging.apache.org/log4j/2.3.x/log4j-slf4j-impl/
So you can use scala-logging, which uses slf4j and drop in the slf4j to log4j implementation to have the logs output via log4j.

[yuri-kiss]

I know I am not a maintainer or a contributor, but I would like to say +1, I personally have never seen it used in any real capacity, and outside of that I myself don't even use it even though I prefer to use log4j2 in my scala projects, I just use the Java API instead.