AW: POI PMC roll call

[a...@dua3.com]

Hi,
I don’t find much time to contribute. I look into the dev list from time to 
time and occasionally respond or comment on issues, but it has been some time 
since I last contributed any code. Reason is that my current dayjob does not 
involve POI anymore and in the remaining time I am preparing to start a small 
company which has now become my “nightjob”. So I might occasionally make a 
small contribution, and there might be a moment when I will find more time for 
POI again, but I have no idea when that will be.
Regards,
Axel

AW: Eclipse / Intellij project files

[a...@dua3.com]

Hi,

I usually don’t like to have IDE specific project files in version control and 
instead having maven or (better) gradle build files only. So I’d vote for B).

As for the code style: has anyone tried .editorconfig? Alternatively, how about 
using a gradle/maven plugin like Spotless for formatting, so that would be 
independent of the IDE.

Another con IMHO is that not only the build files have to be updated for 
dependencies, but also the project files, and to avoid having outdated project 
files in VCS, everyone would then have to use both IDEs to be able to update 
the project files.

Axel

Von: Andreas Beeker 
Datum: Freitag, 26. März 2021 um 17:39
An: POI Developers List 
Betreff: Eclipse / Intellij project files
Hi Devs,

currently we have Eclipse project files in the trunk and svn-ignored IntelliJs 
ones.

A) Would it make sense to also include Intellijs settings?

Pro:

- We could set code format styles.
I once worked in a $dayjob project where each source was auto-formatted.
A few formatting cases looked ugly, but the code style looked uniformly.

- I've corrupted my local project files recently when adding the gradle build.
   So we would have at least a last good known setting.

Con:

- 
https://stackoverflow.com/questions/14558450/why-ide-specific-project-files-are-ignored-in-git

- having the gradle build as a base maybe makes manual configuration unnecessary


B) If we decide to not include IntelliJ file, is it ok, if I also remove/ignore 
Eclipse project files?
... as the would need to be updated for each new dependency


Andi


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Logging

[a...@dua3.com]

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 :
> 
> 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
>  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