First-class slf4j support

[delanym]

Is your feature request related to a problem? Please describe.
Its not clear how to configure kryo to use slf4j.

I see this
#118

With this dead link:
https://code.google.com/archive/p/minlog/#Output_customization

Then this
https://github.com/jdanbrown/minlog-slf4j

And
https://github.com/dorkbox/MinLog-SLF4J

Depends on:
https://github.com/dorkbox/Updates

The only thing I care about logging is it must all go through slf4j.

Describe the solution you'd like
Clear instructions on the kryo page how to configure for slf4j.

Describe alternatives you've considered
The author should maintain an slf4j drop-in replacement for minlog and not defer this to community.
Now I have twice the risk and extra justification to my superiors for using kryo.

It doesn't matter how simple minlog implementation is, its always going to be more complex than just using the existing logging.

[delanym]

Regarding upstream improvements for kryo/minlog:

minlog should ship a minlog-slf4j bridge artifact. This is the same pattern as commons-logging → jcl-over-slf4j, or log4j → log4j-over-slf4j. Users would just swap the artifact coordinates and get SLF4J routing. The Log class API is small and stable, so a bridge module would be
trivial to maintain.

Kryo should use minlog through an interface, not a static class. The fundamental problem is that com.esotericsoftware.minlog.Log is a concrete class with static methods — there's no seam. The only way to replace it is classpath shadowing (what we just did) or setLogger() (which
still requires the minlog jar). If Kryo accepted a logging abstraction through its constructor or through an SPI (ServiceLoader), users could provide any backend without classpath tricks.

Alternatively, Kryo could depend on SLF4J directly. Minlog was written when SLF4J wasn't ubiquitous. In 2026, every non-trivial Java project uses SLF4J or System.Logger. Kryo could drop minlog and log through SLF4J natively, with a minlog-compat bridge for the few users who
actually want minlog's behavior. This would invert the current problem — the majority gets zero-config logging, and the minority opts in to the niche adapter.

Are you open to direct dependence on SLF4J and a minlog-compat bridge?

[theigl]

Are you open to direct dependence on SLF4J and a minlog-compat bridge?

Yes, I think an optional dependency would be OK. Do you want to create a PR with a bridge?

[theigl]

The question is, how this bridge would work. The repos you posted contain a custom implementation of com.esotericsoftware.minlog.Log. If we ship that with Kryo, everybody with SLF4J on the classpath would be switched over automatically. This is a breaking change.

Minlog already supports overriding the default logging behavior like this:

Log.setLogger(new Log.Logger() {
	static final Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Log.Logger.class);
	
	@Override
	public void log(int level, String category, String message, Throwable ex) {
		// route logs to slf4j LOGGER
	}
});

Ideally, minlog would ship such a Slf4jLogger implementation, so not every library that uses it needs to create their own.

@NathanSweet: Do you have an opinion on this?

[delanym]

I see that turning minlog into an implementation of slf4j would strip away its key architectural advantages, rendering it incapable of compile-time bytecode elimination. So I added a bridge instead:

EsotericSoftware/minlog#17

Users who want SLF4J integration add com.esotericsoftware:minlog-slf4j and call install() at startup.