We, the three people that initiated this proposal, want to unite the community, and no longer compete between Log4j API and Slf4j API. Being in the Log4j community for 15 years and experiencing log4shell first hand I think it is long overdue.
The Java world, in my opinion, urgently needs a common API that ends the logging framework discussion and let's everyone switch their provider as they please.
I totally agree that more commonality is needed in logging frameworks. However, I totally disagree that such commonality should be driven by API.
There are multiple logging APIs and we are all used to bridging back and forward between them to get logs arriving at a specific framework that gives the semantics/handling/formatting etc. of our choice. Changing APIs is not a huge problem (Jetty has done it on at least 3 occasions internally and it has little effect on end users because we always defer the ultimate choice of actual framework to our users - or use our own implementation if they don't care).
If you specify a new logging framework that has compelling features, then does it really matter if we use its API directly or bridge to it from existing APIs (or our own APIs)?
So make Jakarta Logging API-neutral and instead focused on the naming, handling, configuration etc. aspects of logging. Projects and other logging frameworks will adopt it based on compelling features, not because of its API.
