The only realistic way to break compatibility in the API is to introduce a v3 API and make the v3 Core implement both the v2 and v3 APIs (or breaking that into two modules, but that introduces more log bridge confusion which is already a huge mess thanks to people continually reinventing logging APIs instead of using log4j-api (or slf4j-api even; seen plenty of projects that introduce their own log adaptor to further fragment things).
If the v3 API was introduced purely to remove MessageSupplier (which can be replaced with Supplier<Message> or Supplier<? extends Message> as we already support) and our custom Supplier<T> interface, then I don't think that's enough changes to warrant the introduction of a brand new API. On the other hand, if we could aggregate enough changes that break compatibility to warrant a v3 API, then I could support that idea more. However, I'd hope that such a breakage would be more than removing deprecated things or merging extension classes (such as flattening the Foo2 classes into Foo). It could potentially be interesting to consider offering multiple APIs for different use cases (e.g., having a minimal API that has a small jar size that can use lambdas rather than parameter arguments), but that's somewhat orthogonal here. On Thu, May 12, 2022 at 3:31 PM Ralph Goers <[email protected]> wrote: > > > > > On May 12, 2022, at 10:15 AM, Chris Hegarty <[email protected]> wrote: > > > > > > My motivation for bringing this up now is just to explicitly highlight the > > consequences and potential wide impact of such a change, not to make any > > concrete suggestions. It's a difficult balancing act to weigh compatibility > > against making progress, but ultimately j.u.f.Supplier is the right choice > > (there are just different ways to get there). > > Any ideas on how to get there? The one proposal Gary made was to require > log4j3 artifacts and renaming all packages to org.apache.logging.log4j3. The > consequences of this would be: > a. Both are on the classpath - unless we change log4j2.xml to log4j3.xml and > change all our property names then both will try to load the same logging > configuration, which is bound to be problematic. > b. We create a bridge in log4j3 for the log4j 2 api. I just see this as a > mess and confusing to users. > > FWIW, the impact of us using our own Supplier seems non-existent since anyone > using those methods would be providing a lambda expression. > > Ralph
