Skip navigation

To use SLF4J or not, that is the question

UPDATE: It's noteworthy that the logging layer we are discussing on is not part of user API. That is, it's not intended for use by users but by developer (committer).

There was recently a discussion in the community about whether we should switch from our own logging layer to something else such as SLF4J or java.util.logging in Netty 4. The following is the list of the options we discussed and the related opinions:

  • Keep the current thin logging layer and modernize it so that it's as easy to use as SLF4J.
    • Why: Zero dependency. Netty itself does not log very much.
    • Drawback: It doesn't make much sense to have a logging layer. Netty should focus on I/O.
  • Use SLF4J.
    • Why: A lot of open source libraries already use SLF4J. Nice API. Zero dependency is not really a problem because your application's classpath will probably have SLF4J anyway because other open source libraries you depend on use it.
    • Drawback: Non-zero API. People not familiar with setting up SLF4J might have difficulties to run their first Netty application.
  • Use java.util.logging.
    • Why: Zero dependency. Netty doesn't need to provide a logging layer.
    • Drawback: Unfriendly API. jul-to-SLF4J bridge has very poor performance.

We are probably not going to choose java.util.logging, but we are undecided whether we should switch to SLF4J or not. What is your opinion? It is very likely for us to respect your comments as much as possible for decision making, so please feel free to leave a comment so that we listen to you and understand what you value more!