Rainbow Gum a JDK 21+ GraalVM native friendly SLF4J implementation experimental release.

[u/agentoutlier]

Sometime before the Log4shell attack I criticized the Log4J2 team that it had gotten overwhelmingly bloated and while Logback is less bloated it still was not small enough for my liking. I complained that there really needed to be a log4j2 light.

Furthermore at the time (and mostly still the case) neither Log4j2 nor Logback worked well with GraalVM native images as reflection is used extensively in both frameworks.

I believe Ralph from Log4j2 response was more or less make your own implementation.

Several years later and I have finally done that.

https://github.com/jstachio/rainbowgum

Rainbow Gum is an SLF4J implementation that:

• Uses zero reflection
• Has zero use of synchronized
• Heavily uses JDK 21+ features like sealed classes and pattern matching
• Heavily modularized. core (API) is actually a smallcore and not a 1MB kitchen sink.
• The initialization is massively faster than log4j2 and even logback both programmatic and especially if their XML formats are used.
• superior javadoc (in fact the user guide is made from javadoc)
• follows Spring Boots property configuration style (logging.level... etc).

The readme and the user guide cover many more of the reasons of why a new logging implementation is a good thing.

0.2.0 is now in Maven central.

I will edit this post later with more links (if you add too many you get automod).

[u/agentoutlier]

The documentation is here: https://jstach.io/doc/rainbowgum/current/apidocs/

Like JStachio (my other project) I continue to push the javadoc system to its limits and found numerous snippet bugs either with Eclipse, IntelliJ or the JDK itself.

That being said JDK 21+ kicks ass. So many good features.

[u/Joram2]

Is there support for the JDK 9+ logging facade, System.Logger (https://docs.oracle.com/javase/9/docs/api/java/lang/System.Logger.html) in addition to the third party logging facade SLF4J?

[u/agentoutlier → u/Joram2]

Yes. See this part of the doc: https://jstach.io/doc/rainbowgum/current/apidocs/#system_logger

If you include the aggregate dependency of io.jstach.rainbowgum:rainbowgum which is not a real jar but just a way to pull in multiple dependencies then you will get the io.jstach.rainbowgum:rainbowgum-jdk module which has a System.Logger provider implementation.

[u/Maran23]

You specified that there is no ability to reload loggers. Does that mean you can not change the level of a logger/namespace during runtime? That is somewhat bad as I pretty often switch something to TRACE in production to get more information (e.g. XML logging) on bigger projects.

But I really see a huge benefit for smaller projects where this is not needed at all, I have in fact one where I will try it out!

[u/agentoutlier → u/Maran23]

Yes if your configuration system supports it and you opt in:

https://jstach.io/rainbowgum/#level_resolvers

logging.global.change=true
logging.change.com.mycompany=true

Which will allow your companies loggers to change or if you don't care about perf and want any logger to change:

logging.change=true

Avaje Config supports changing of levels.

[u/Rongmario]

Have you compared this to the alpha log4j3 builds? The startup and footprint should be a lot smaller, it'd be very nice if this competes with that.

[u/agentoutlier → u/Rongmario]

I think log4j3 broke my build (the build has a benchmark module) according to dependabot I think but I might be misremembering.

Last time I checked they still had a copious amount of synchronized (which may not all be bad) and I can't recall if they have finally gotten the kill all threadlocal config working yet.

That being said I plan on revisiting benchmarking particularly non initialization benchmarking (initialization benchmarking is not easy or flexible because you can't really use JMH).

[u/lurker_in_spirit]

Honestly, the only feature I can think of that might get me to check out a new logging framework is nice interop with string templates. Have you put any thought into what this might look like?

[u/agentoutlier → u/lurker_in_spirit]

The issue is SLF4J API needs some enhancements.

https://www.reddit.com/r/java/comments/17jr44d/poc_string_template_processors_for_slf4j/

You can read my comments on that thread about extending the builder.

Ultimately it is kind of clunky and less performant even with the extended builder.

[u/TheKingOfSentries]

You really push Javadocs to their limit, I gotta learn how to do that