Why would I prefer Rainbow Gum over the built-in Java 9 System.Logger?

[hrstoyanov]

Please covience me.

[agentgt]

System.Logger is a facade just like SLF4J and not an implementation. Rainbow Gum provides no logging API of its own on purpose. It provides backing implementations of both SLF4J and System.Logger. So it is more a question of why use SLF4J over System.Logger.

The default implementation of System.Logger will use java.util.logging which is incredibly inefficient and has very few output styles (I think only file and console). Furthermore its parameter replacement uses MessageFormat which again is incredibly inefficient.

That being said if one uses System.Logger without parameter interpolation (uses the condition checking and then concat strings) and a faster backing implementation or bridge it is mostly fine.

What happens in frameworks like Spring Boot, Micronaut or Quarkus is that they use the System.Logger -> SLF4J bridge System Logger Bridge -> Logback/Log4j2. You can use that approach in Rainbow Gum as well but there are caveats that are discussed here: https://jstach.io/doc/rainbowgum/current/apidocs/#system_logger

[agentgt]

So basically and I will add this to the official docs. If you only want System.Logger:

You add these deps:

• io.jstach.rainbowgum:rainbowgum-core
• io.jstach.rainbowgum:rainbowgum-jdk
• io.jstach.rainbowgum:rainbowgum-pattern (if you want pattern formatting)

Then if you are only doing console you do

-Dlogging.systemlogger.initialize=true
-Dlogging.appender.console.encoder=pattern
-Dlogging.encoder.console.pattern=%d{HH:mm:ss}] [%-4level] %msg%ex%n

That will roughly match the JUL settings you have.

[hrstoyanov]

Thank you @agentgt , will try it soon!
Just to re-iterate - I don't want SL4J used automatically/auto-detected, just because it happens to be on the classpath/modulepath. This should be under the strict control of the developer, and permitted (or disabled), perhaps with a system property.

[agentgt]

Yes so long as you do not put

io.jstach.rainbowgum:rainbowgum-slf4j

in the class/modulepath you are good to go it. Do not include as a dependency that is why I listed the ones you need.

Note that

io.jstach.rainbowgum:rainbowgum

includes rainbowgum-slf4j so you don't want to do that.

(the above is Maven GAV Coordinates minus the version).

Just be aware that if any of your dependencies use SLF4J they will try to load it but it will not load Rainbow Gum however it you will get a nasty gram from SLF4J that it could not find anything.

The auto-detection I was talking about is not using reflection (well not the bad kind) but the java.util.ServiceLoader and even that is done as you said through a property:

https://jstach.io/rainbowgum/io.jstach.rainbowgum.systemlogger/io/jstach/rainbowgum/systemlogger/RainbowGumSystemLoggerFinder.InitOption.html

That InitOption choices are what you feed to:

-Dlogging.systemlogger.initialize=

This isn't so much about loading SLF4J it is about whether not the System.Logger loads Rainbow Gum or queues and waits for something else to load.

Copy from javadoc:

CHECK
(default) Will check if there are implementations of RainbowGumServiceProvider.RainbowGumEagerLoad and if there are not will load rainbow gum.
FALSE
Will not initialize rainbow gum.
REUSE
Will reuse an existing rainbow gum or fail.
TRUE
Will initialize rainbow gum.

I realize it is a little confusing and I will try to improve the doc some more.

[hrstoyanov]

Thanks @agentgt - dropping the jar as means to control SL4J usage is fine. I admit I did not read the complete docs yet, but hopefully my question help with what need to be answered for newcomers first

[agentgt]

Your input is super valuable. It reminds me where there are holes in the doc that I need to fix.

Part of why Rainbow Gum is so modular is exactly for your use case but sadly I had to make the easy path for those that use SLF4J as most do.

Neither Logback, Log4J2, or even Tiny Log would let you do what we just talked about. Logback is especially bad as its core depends on SLF4J!