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
