5 ms·
This is a well understood problem and I think the design pattern SLF4J uses has become quite popular. The ability to allow consumers to bind at runtime the imp
by setheron 10y ago
This is a well understood problem and I think the design pattern SLF4J uses has become quite popular.
The ability to allow consumers to bind at runtime the implementation they want by providing an api jar is kind of a neat idea.
The thing I dislike the most is when libraries force me to use their logging runtime. If they need it just for tests they should add the 'test' scope and just use the 'api' jar as a 'compile' dependency.
- btilly 10y agoIt has become popular, but it is still wrong. If you're a nested dependency, then DON'T require end developers to be aware that you're there. Doing so makes you a leaky abstraction. http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... Though the author does have a point that fault here could be put on the library that added the dependency without a default logging behavior. However I'd still blame SLF4J for making the default case suboptimal.
- emodendroket 10y agoBut it seems useful because you can decide what behavior your want for your project.
- btilly 10y agoRight, it is configurable. But there is no reason why a configurable library can't have reasonable default behavior if no configuration is supplied. While still being configurable. If you're winding up as a buried dependency that end developers may not be aware of or care about, you want to do this.
- emodendroket 10y agoTrue enough. I guess the main downside would be including a library that may never be used.
- vertex-four 10y agoWhat reasonable default behaviour? If you're writing a console application, dumping to stderr is probably not a good idea - writing random log files that the end-user/admin has no idea about is probably not a good idea - shutting up and doing nothing is probably not a good idea (Java code has a tendency to use logging to warn about non-fatal configuration errors, etc). And let's not get started on what verbosity to set by default.
- btilly 10y agoA good default is to write to STDERR if the severity level is above some threshold, otherwise do nothing. That way the console can tell you about configuration errors, and by default the library will log nothing. If the library author considers it important to log somewhere, the library author is responsible for putting both an understandable warning up, and writing documentation.
- marcosdumay 10y agoIf you are creating a library? You shouldn't log at all. Return errors or throw them - do not log. If you are creating a console application? Stderr is the standard way to log errors. Let the user decide if where it points to. If you are creating a daemon, set the log destiny at the launch script. The application can either log to stderr anyway and let the script handle everything, or offer a parameter for setting the log channel. The Java community fixation on logging is really not deserved. It's more caused by bad error handling by their main web servers than by any fundamental problem.
- empthought 10y agoLogging is useful for more than just error conditions; how does that square with your advice to library authors?
- marcosdumay 10y agoIf it's not an error condition, you return it. Libraries must not do any covert IO (in fact, any covert anything). A logging library is the only one that should log, and not their own messages. They may write into some main application supplied collector, if it is not global, or if it is clearly handled as a message passing API. The Java way is simply bad.
- phillord 10y agoIt doesn't force anything though, unless you statically refer to the runtime. It does force you to exclude their logging backend, but that is straight-forward enough.
- theanomaly 10y agoYes, but you have to know to exclude their backend. And, that library may be several dependencies deep. Now you're expecting potentially junior developers to have the insight to grep their entire transitive dependency tree, find the nop dep, and exclude it. This kind of silent failure is worse than the alternative.
- duaneb 10y agoDependency exclusions is a code smell everywhere but java. I don't understand why someone is actively giving this advice.
- phillord2 10y agoThe alternative is not specifying a nop dependencies and then inflicting on downstream uses the choice that I was not prepared to make.