Hi Andi, two more things to consider:
- Jigsaw support. The module system has been around for some years now, and libraries still have to fully support it. From what I read, Log4J2 seems to support Jigsaw, whereas SLF4J/Logback still only has it in Beta-versions. - Active development. The last SLF4J happened in 2019, about the same time that the last alpha release with Jigsaw support was made. The dev list for both SLF4J and Logback only seems to have three kinds of entries: Someone volunteering to help or asking for same, automatically posted JIRA updates, and Rory O’Donnel announcing the availability of a new JDK build. So if JUL is not an option, I would definitely go for Log4J2. Cheers, Axel > Am 27.01.2021 um 00:48 schrieb Andreas Beeker <kiwiwi...@apache.org>: > > Hi Axel, > > my ideas against JUL and pro SLF4J / Logback / Log4j 2: > * I prefer a logging framework which is able to bridge commons logging, as we > have dependencies which use commons logging. > * as a library we should pick a logging framework / stubs, which users > typically use - if we use JUL, they likely need to use an additional logging > bridge ... I think it's futile to set a KISS trend here :) > > Apart of that, I don't think, we would benefit much by performance gains, as > logging is not really a POI-thing ... > > Andi > > > > On 26.01.21 23:42, a...@dua3.com wrote: >> Hi, >> >> just want to know what are your thoughts about not using any third party >> logging framework and instead go with plain JUL logging? Slf4J, Log4J, and >> all the others had been created to solve shortcomings in JUL. But JUL has >> much improved, and messages can be created using lambda formatters which >> gives you really much flexibility. >> >> - no non-JDK dependencies needed >> - whatever logging framework your application uses, it will provide support >> for integrating JUL >> - available on all platforms >> >> In my personal projects, I have removed the logging frameworks and gone back >> to JUL and life is much simpler now. >> >> Cheers, >> Axel >> >> Von meinem iPhone gesendet >> >>> Am 05.12.2020 um 23:36 schrieb Marius Volkhart <mar...@volkhart.com>: >>> >>> Hello, >>> >>> POI currently uses a custom facility for logging: the POILogger interface. >>> This serves as a level of indirection to allow consumers to plug in a >>> logging implementation of their own. Best as I can tell, this facility was >>> added nearly 10 years ago, and the logging landscape has changed a lot in >>> that time. I'd like to revisit this facility. >>> >>> The impact of temporary objects due to logging has been of increasing focus >>> in the last few years. Projects like Apache Log4J have gone to great >>> lengths to reduce the number of temporary objects created for logging >>> purposes, and run garbage-free in some configurations. At this time, >>> POILogger is comparatively garbage heavy. Every call to POILogger.log(int, >>> Object...) requires at least an Object[] allocation, even if the message >>> won't be logged. In many cases, string concatenation is done before calling >>> log(int, Object...), resulting in more allocations. The logging frameworks >>> like Log4J have solved this by adding overloads that take a varying number >>> of arguments. >>> >>> Once inside of log(int, Object...), if it is determined that the message >>> should be logged, the common case of a single Object array is not optimized >>> for. Furthermore, the log forging escape regex is compiled every time. >>> >>> Despite providing an indirection of it's own, POI still has a hard >>> dependency on Apache Commons Logging, and ships with a POILogger >>> implementation that defers to Commons Logging. >>> >>> The performance topics could all be addressed without much difficulty. The >>> question I pose is, should they be? Other Apache projects exist to focus on >>> the problem of how to do logging well. I propose that POI uses one of the >>> logging frameworks directly, rather than having the POILogger abstraction. >>> 10 years ago, logging frameworks didn't split their API and backend the way >>> that Log4J and SLF4J/Logback do today, so the need for an indirection was >>> greater. >>> >>> Commons Logging is already a dependency, so it may seem a logical choice is >>> to use it directly. However, Commons Logging has a very limited API, which >>> would make POI authors write more logging code than they do now. It also >>> suffers from high garbage. >>> >>> Instead, I propose that Log4J is the more logical choice. It's a popular >>> logging framework, under the Apache umbrella, and is a leader when it comes >>> to considering performance while providing rich logging APIs. Using the >>> Log4J API lets application authors decide if they want to use Logback, >>> Log4J Core, or some other logging backend, and gives them a lot of >>> flexibility in how logging is done. >>> >>> Of course, removing POILogger is an API change. However, it is marked as >>> being @Internal, and previous discussion >>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are >>> unlikely to be many users of this API. This feels like a change that could >>> happen after the 5.0 release. >>> >>> I would like to complete this work, and would also write new documentation >>> to explain how POI submits log events to the Log4J API. >>> >>> Proposed changes: >>> - Remove Commons Logging dependency >>> - Add Log4J API dependency >>> - Remove POILogger API >>> - Remove POILogFactory API >>> - Modify all log sites to use Log4J API >>> - Write new documentation for how POI submits events >>> >>> -- >>> Cheers, >>> Marius Volkhart > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
