There’s @Deprecated(forRemoval = true) which can rise different warnings or errors from a regular deprecated element. — Matt Sicker
> On May 13, 2022, at 16:32, Ralph Goers <[email protected]> wrote: > > 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 >>> >
