We currently use SLF4J API in our library
And for our unit tests and demos we need to use a concrete implementation.
Currently we are using logback.

Logback Security Policy concerns

But we faced several time situation where logback was affected by security issue and maintainer refuse to back-port small and simple fix to old branches... :

• Backport CVE-2024-12801 & CVE-2024-12798 to 1.2.x? qos-ch/logback#899
• Backport CVE-2025-11226 to 1.3.x? qos-ch/logback#974

I have concern with that kind of policy which consist by forcing users to :

• either upgrade to more recent version of logback (and so force to increase the minimal java requirement)
• or fix that on their own and so maintain their own custom version of logback...
• or pay for a news release ...

Bad feeling about maintainer

Deleting comments
It's up to maintainer to decide their security policy but in practise this doesn't really fit our needs.
I try to explain that with a comment on an issue and maintainer decide to delete my comment... 🤦

Refuse(not encourage) contribution
Another point, some users propose to help to back-port vulnerability fix and he refused because of "lack of time"

It does not seem to be in the best interests of the community...

Migrate to log4j2 ?

So is there a good alternative ? It seems that log4j2 is a really mature project.

• ✔️ It seems to have a better Security Policy.
• ✔️ This is a community project (several contributors) where logback is a one man project.
• ✔️ log4j2 seems to be more conservative regarding minimal java version requirement (8 for log4j2 vs 11 for logback)
• ✔️ It seems that performance is now better for log4j2.
• ❌ the only drawback the jar size around 2Mo for log4j2 against ~1Mo for logback.

So I think we should consider to migrate ...