I believe we moved the things in Foo2, Foo3, etc to the parent as default methods but left empty interfaces or classes in their place so that compatibility wouldn’t be broken. In an ideal world it would be nice to have a way to prevent them from being used when compiling. Perhaps an annotation that causes an error?
Ralph > On May 13, 2022, at 11:48 AM, Gary Gregory <[email protected]> wrote: > > I certainly would hope that collapsing Foo2, Foo3 into their parent is up > for consideration for 3.0. Memories of Microsoft COM and DCOM... > > Gary > > On Fri, May 13, 2022, 13:36 Matt Sicker <[email protected]> wrote: > >> 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 >>
