Bump the Java version to 11 in SLF4J version 2.1.0

[ceki]

Moving the Java requirement from Java 8 to Java 11 in SLF4J version 2.1.0 is being considered.

We are seeking input regarding this change in requirements.

The desire upgrade to Java 11 stems from the difficulty in maintaining both Java 8 and JPMS support in the SLF4J build. The build is rather complicated.

Update: Given the widespread use of SLF4J, it stands to reason that SLF4J should stick to Java 8 for the moment. As such, SLF4J version 2.1.0-alpha1 reverted to using Java 8.

[KengoTODA]

Since Java 11 has reached its end of life, I believe using Java 17 would be a good option too.

[anbusampath]

As @hazendaz mentioned Spring Boot 3+ require Java 17, also Microunat 4, Quarkus 3.7+ required Java 17. Library authors can stay on Java 11, but if all Java ecosystem libraries and frameworks move to Java 17, it would great from end user perspective.

[hkupty]

I think moving to jdk 17 should be prioritised over jdk11, though I see the logic in bumping to 11. One could increase the requirement to jdk 11 in 2.1.y and to 17 in a subsequent 3.x.y series

[albertus82]

Logging libraries are probably the most used dependencies of all. IMHO any unnecessary upgrade will limit the adoption of SLF4J and perhaps even Logback.

[hazendaz]

If this helps at all, the only other real player in this logging 'wars' as they use to call it is Log4j already made their call, see https://logging.apache.org/log4j/3.x/.

[xzel23]

For me, Java 8 is a real pain. Many dependencies I use don't have proper JPMS support, and patches or PRs are sometimes refused because either a JDK 9+ is required for building, or fear that a module-info breaks things for people still on 8. I really welcome each and every library that does the step to at least Java 11. In the case of SLF4J, we already have proper module support (thank you, @ceki), and I don't know if SLF4J users would benefit from a better API that might be possible using 11 or 17. But going to at least 11 would put more pressure on other projects to finally move on.
So I could understand if SLF4J stayed on 8, but I hope for 11 or even better 17.

[bmarwell]

Yes, please do an 11/17 upgrade (11 is almost EOL even with extended support), but please bump to a new major version!

Can't wait for new APIs to be added! 👍🏻

[marcwrobel]

I don't agree with #379 (comment):

Since Java 11 has reached its end of life, I believe using Java 17 would be a good option too.

and #379 (reply in thread) :

For reference to jdk 11 end of support -> https://endoflife.date/oracle-jdk

Only mentioning Oracle JDK, which is a commercial Java distribution, is not very representative IMO. Here are a few other dates for some OpenJDK distributions (source : pages on https://endoflife.date/tags/java-distribution):

• Eclipse Temurin : At least Oct. 2027 for both OpenJDK 11 and 17,
• Amazon Corretto: Sept. 2027 for 11, Oct. 2029 for 17,
• Azul Zulu: Sep. 2026 for 11 (Sep. 2028 with commercial support), Sep. 2029 for 17 (Sep. 2031 with commercial support).

Given those dates, I think an upgrade to JDK 11 is still a thing to consider.

I agree that there is no point keeping JDK 8/11 compatibility if almost all major frameworks / libraries raised there compatibility level to 17. But SLF4J being a basic bloc for many applications, I think it should at least lag behind all those frameworks in term of Java compatibility.

So my opinion is: keep the JDK 8 compatibility for now if it's manageable (meaning if it does not become a security risk / if it does not take too much time / or even if it does not prevent doing some nice improvements to the API), or upgrade to 11 otherwise.

[giacgbj]

Baseline Java 17 and a critical vulnerability (CVSS>9, at least a remote code execution) in the previous version would be great to force applications' upgrades 😉

[albertus82]

...or to migrate to another logging library.

[xzel23]

I estimate the switch to another logging library would be more effort than moving to 8, and given that log4j will also move to 17, there's not much to chose from anyway.

[athspk]

Anything >= 17

[henjovr]

Java 8 is still widely used in big (slow!) enterprises, so unless you want people to migrate away from SLF4j, keep supporting Java 8.
It is an interface and a facade. Keep it simple. In my opinion a logging framework shouldn't need the latest Java features to function correctly. A logger binding - perhaps - but not the facade.

In my opinion, SLF4J is clean, stable and robust as it is now (2.0). Please keep it clean, stable and robust.

Maybe an idea: keep 2.x for Java 8 (and support it), make this breaking (!!) change into a 3.x version.

[sysmat]

In my opinion this is valid point, if interface don't use language features from java X why bump it

[ceki]

@henjovr Thank you for your comments which make a lot of sense. SLF4J version 2.1.0-alpha1 reverts to Java 8 as a requirement.

[henjovr]

Thank for listening, much appreciated :)

[michael-o]

SLF4J is a fundemental library, therefore it should be fundamentally available to everyone and not to fraction of people: Java 8+ for everyone.

[michael-o]

Again, we are not talking about not supported Java versions. Java 8 will live until 2030 for many vendors. Stop spreading FUD, whether someone is willing to support Java 8 in his codebase is a different discussion.

[bmarwell]

I know that (some vendors do SECURITY updates until 2030, no new features like TLS versions etc). I just wanted to imply that a 3.x version would be beneficial for Java 17+ users as long as v2.x is still being maintained (eg security fixes). i don't see where this is FUD.

[bmarwell]

For Oracle Java, even Premier support already ended in 2022: https://www.oracle.com/java/technologies/java-se-support-roadmap.html. They are on extended support, which (don't know, but most probably) means that no new features will be added, like new TLS versions, ciphers, etc.

For IBM Java, it is 2025, which is way sooner: https://www.ibm.com/support/pages/java-sdk-lifecycle-dates

Eclipse Temurin EOS is April 2026 (Azul): https://www.azul.com/products/azul-support-roadmap/. However, they do offer support until 2030, too.

Based on that, I do not consider my comment to be FUD. However, I am sorry if the wording caused any confusion. CC @albertus82.

[albertus82]

If none of the features of JDK 17 are really useful for the development of SLF4J, I think there's no need to start another branch (3.x) that in turn would also introduce a maintenance cost without any added value.

[bmarwell]

That's a very fair point.

[ijuma]

Another point of view is that there is slf4j 1.x for people who are on older Java versions. Generally, the ecosystem is moving on, see https://youtu.be/NxpHg_GzpnY?si=wA57g9kAhYulrlUO&t=411

[michael-o]

Then the lib should move to an honest 3.x.

[opwvhk]

As mentioned by others, Java 8 won't be gone just yet. In fact, Azul Zulu 8 will be supported until the end of 2030 (almost 7 more years!), with security fixes for 2 more years after that. So come up with actual usage statistics or expect people to migrate to something else.

However, supporting Java 8 does not mean that there is no room for innovation! One option is to use a Multi-Release JAR (JEP 238).

The advantage of that is that SLF4J will still work with Java 8, but there is the option of more functionality for Java 9, 11, 17, ..., such as an implementation of System.Logger.

[Geolykt]

Just for your information, SLF4J does already use multi-release jars for the module-infos. From my experience doing so isn't fun though as buildsystems are really bad at combining Java 8, JPMS (also known as Jigsaw) and MRJ. Ultimately this is a write-once-forget-forever kind of situation. Especially maven does treat that system a little bit better than Gradle but you need to do a non-zero amount of setup regardless.

[hkupty]

Just a note on Java8 usage statistics:
2019 -> 83%
2020 -> 75%
2021 -> 72%
2022 -> 60%
2023 -> 50%

It is still relevant, but losing relevance rapidly...

[xzel23]

... and I bet that 90% of the developers still using Java 8 on a regular basis hope that some important library they need switches to at least 11 so that they can convince their management to update ;-)

[albertus82]

Nope, the management will convince 'em to switch to another library.

[xzel23]

Ah, that one should be easy. The other big logging library has already announced they will switch to 17. They can tell management there are no widely used logging libraries left that still support Java 8. Even JUL logging is on Java 21 with the latest release (just don't tell management that it's part of the JDK and so JDK 8 support will be there as long as Java 8 is around).

[hkupty]

In the context of a logging façade library, bumping the java version means that java 8 apps will be forbidden to use the newer APIs, period. Writing logs is the responsibility of the underlying libraries, like logback, log4j or penna (this last one already caps the support to java 17 anyway).

It doesn't pose any immediate requirements to apps running java 8 to upgrade and the short-term impact is that they will not be able to refactor to use the newer API. Longer term, they will not be able to update dependencies that use newer SLF4J version.

I wonder how many apps running java 8 are keeping all the dependencies up-to-date to really feel the impact.

The concerns feel much worse in theory than in practice it seems to me..

[Geolykt]

As someone that actively develops a program (well it's actually a modification to one, but for the sake of this argument that is not all that relevant) for Java 8 I can actually say that I do intend on keeping all my libraries up-to-date even though I use Java 8.

Yes, SLF4J not supporting Java 8 in the future is a minor issue for all API consumers, but as others raised doing so in version 2.1.0 is inappropriate. Outside of that it is my firm belief that all API providers should support as many systems as possible, while still remaining within the bounds of sanity. One could make the argument that you can "downgrade" Java 9+ artifacts to Java 8 - projects for that exist. Whether that should happen when compiling SLF4J or when compiling whatever project consumes it is up to the maintainers - both ways have their drawbacks (and they aren't perfect anyways - pick your poison).

[hkupty]

but as others raised doing so in version 2.1.0 is inappropriate

I can agree with that.

all API providers should support as many systems as possible

I see your point, but I can think of cases where that would be impractical. I don't think that's the case for SLF4J though.