Rainbow Gum 1.0.0, Logging Backend for Java, Released

Rainbow Gum 1.0.0 has been released. It is a logging implementation for the JVM, under the BSD 3-Clause license, for Java 21 or later.

Rainbow Gum is a backend, not a facade. Your code keeps calling SLF4J, System.Logger, java.util.logging, the Log4j2 API, JBoss Logging or Commons Logging. Rainbow Gum takes the place of Logback or Log4j2 under them.

What it claims

The project's comparison page, why_rainbowgum_is_better.md, makes four main claims:

• Safer. The core has no XML parser and no expression language. Log messages stay data, so nothing like Log4Shell's lookups can run. A bad configuration fails at startup with context, instead of being ignored.
• Smaller. The core needs only the java.base module. Logback and Log4j2 pull in java.xml. The project measures Rainbow Gum's core and SLF4J jars at 429 KiB, against 921 KiB for Logback. Those figures are for older versions (Rainbow Gum 0.11.0, Logback 1.6.3).
• Faster. In the release announcement on Reddit, the author says it is faster than Log4j2, and that Log4j2 is often slower than Logback.¹
• Modern. It is built on Java 21, with sealed types and JSpecify nullability annotations. It has colored console themes, and the core includes JSON, logfmt and LTSV encoders.

The comparison page also points out the obvious: Rainbow Gum has a shorter track record and less scrutiny than Logback or Log4j2.

There are limits. The core does not load a configuration file on its own: configuration comes from system properties, from your framework, or from an optional module that reads logging.properties. There is no date-based file rotation, only a basic size-based rolling output. There is no support for SLF4J Markers.

Configuration without XML

Rainbow Gum reads properties, and its names follow Spring Boot's: logging.level.com.example=DEBUG, logging.file.name=app.log, and so on. A Spring Boot application keeps its existing logging.* settings. Rainbow Gum even reads Spring's logging.logback.rollingpolicy.* properties and maps them onto its size-based rolling output.

For Spring Boot 4, the switch is two changes to the POM: add rainbowgum-spring-boot4-starter, and exclude spring-boot-starter-logging. One way to do the exclusion is to declare spring-boot-starter yourself with the exclusion. Maven then uses your declaration in place of every other starter's copy. There are integrations for Spring Boot 3, Micronaut and Helidon as well.

The project also publishes an llms.txt and a Logback migration guide written for coding agents.

Kicking the Tires

I moved a Spring Boot 4.1 web application from Logback to Rainbow Gum 1.0.0. The application used only the SLF4J API, with no Logback classes, Markers or MDC. The change took a few lines in the POM and a few in application.properties, and production logging worked on the first deploy.

Two things came up in the tests:

• Output capture. Rainbow Gum binds System.out once, when the console output is created. Spring Boot's OutputCaptureExtension swaps System.out per test, so captured output missed log lines. The fix is documented: set the console stream to follow, so it reads System.out on every write.
• Context pausing. Spring Framework 7 pauses a cached test context when a test switches to another context. Pausing runs Spring Boot's logging cleanup, which shut Rainbow Gum down for the whole JVM. The paused context later resumed, but logging stayed off. Logback keeps working in the same sequence. I reported it as rainbowgum#892, and the maintainer replied the same day. Until a fix ships, spring.test.context.cache.pause=never in src/test/resources/spring.properties avoids it².

Should you try it?

If your code uses only SLF4J, a trial is cheap: a POM change, and a revert if it does not work out. If you depend on Markers, date-based rotation, or Logback appenders such as SMTP or syslog, check the migration guide's list of what does not carry over first.

There are only a handful of logging backends for Java. A new one that focuses on startup checks, a small core and plain properties is worth considering.