[paulmd]

No, this guy is 100% wrong. The distinction is absolutely clear. If someone else is expected to build on top of a framework he provides then he is building a library, and it would be inappropriate to tie future consumers to a back-end. This is relatively simple to fix - you mark his library as a dependency and add an additional <exclude> for slf4j-nop to that dependency, but it's not the right way to do this. Those messages aren't meant for him, they're meant for future consumers, and now after including his library they have to dig through and figure out why SLF4J suddenly broke.

I can't find exactly what this Tawny-OWL thing is (his link is broken), but it sounds like it might have some kind of interpreter application provided. If he is offering a finished application within the same build unit as his UI library, this is the "big ball of mud" architecture. The fix is to break his application out into a separate build unit that depends on his library. The application can then include slf4j-nop without messing up SLF4J for all his library's consumers. Maven Reactor can automatically build his dependencies when his main application builds, if desired.

The thing about having to deal with 2 different logging frameworks is exactly what SLF4J is meant to fix. SLF4J lets you route the messages from multiple sources to a single sink/backend defined by the final consumer application. Yeah, it sucks to deal with multiple logging frameworks, but that's simply how it is and you don't help anything by having a whinge about it. You include the routing/bridge modules (JUL-to-SLF4J, Commons-to-SLF4J, etc) in the final-consumer application and call it a day. If you don't want to do that, find some other dependency that doesn't use those logger frameworks.

[phillord]

My framework is built in Clojure. The interpreter is always there. Think of it like a statistics library with R.

The idea of a "main application" is itself not a clear one. There are a set of functions you can use. Whether you choose to launch directly over the library or import it is a matter of convenience.

[paulmd]

I would say that the responsibility to define a backend falls either on the Clojure interpreter or the user of the interpreter, then. Java is not typically run on an interpreter shell and the defaults that normally are sensible for Java probably aren't appropriate there.

It's a perfectly sensible default for a framework to warn you at runtime that it's not configured properly, and stderr is the appropriate channel for that to go out over. I would even go so far as to say that it should default to stderr output on warn/error messages unless explicitly muted, instead of merely switching to NOP output after the initial misconfiguration warning. An interpreter might prefer another default but I think that's probably the best default for most Java projects.

The way I see it here, Clojure built on top of a stack without understanding the caveats that go with the stack. It's simply a fact that Java logging is a mess, there are four major competing standards and you need to tell Java which one you prefer, because any project will eventually need to interact with all of them if it continues growing. It's a fact of building on that stack.

[agentgt]

The problem is that it is a Facade/API that is initializing and printing to STDERR.

I completely disagree with the idea of making slf4j-nop a required exclusion dependency (that is a I agree with @paulmd and not the OP) but a facade/api should have very little interaction with the boot process of Java. The default should be to do nothing and require either a java.util.ServiceLoader like mechanism or some other explicit configuration (or in SL4J's case adding a bridge).

That is slf4j-nop behavior should be the default (not the dependency). I understand that would confuse users but I think it would be the correct behavior. (also see my other comment for more reasons)

[phillord2]

Java is getting an interpreter shell, as it happens.

Logging should default to warn/error on standard err? I find this a strange idea. Having a "--verbose" switch is pretty standard on the command line. Some applications do have an "be absolutely silent" switch, true but that normally switches everything off.

[dantiberian]

I don't think any of this is a Clojure specific issue. You can do all of the same things in Clojure with JVM logging libraries as you can in Java.