I come with evidence, namely my comparison of the performance of JUL, Log4J2 and Logback:
https://www.sitepoint.com/which-java-logging-framework-has-the-best-performance/ Java Utils Logging is horrible in terms of performance. About the only good thing I can say about it is that it give a consistent throughput no matter how many threads you throw at it... consistently crappy throughput ;-) Given how much logging some Jenkins instances do, switching Core to either Log4J2 or Logback should have the potential to make a significant difference to the performance of some instances. So before we all jump into a fight over whether to pick Log4J 2 or Logback, there are a number of questions that we need to resolve: 1. Is Kohsuke on-board. In the past this has been a blocker. 2. We should not change the logging format for existing installations. New installations might get a nicer single-line log message by default, but existing instances would have to configure the switch-over 3. For compatibility issues, users may need to switch back to JUL if they have issues. This likely means that we pick SLF4J as the API that we log with and just configure the back-end on start-up so that you can jump back to JUL if you really need to 4. Support Core plugin will need some rework, are there any other plugins that hard-code assumptions that Jenkins Core uses JUL 5. Remoting may need to bundle the logging framework somehow, or at least "just enough logging framework to bootstrap the real one" What else do we need to line up before we can bite this one off? -Stephen -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwEZUeQLVwcsG%3DyG_hkLCBJU1gNGdZ%2B%3DNywwA5uVWFWUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
