Hi,
Sorry for the delayed response.
Clearly there are many more considerations, when considering v3, beyond
just the Supplier interface, which is completely understandable and as
it should be.
On 13/05/2022 18:35, Matt Sicker wrote:
> 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.
This seems like a pragmatic approach, and FWIW, one which I agree.
There is no "silver bullet" or "magic beans" that can be leveraged to
teach the JVM to automagically consider log4j.Supplier as a j.u.f.Supplier.
This leaves the usual set of less-than-ideal options (enumerated here
for completeness):
1. A new v3.Logger interface - which just uses j.u.f.Supplier.
2. A v2.Logger with additional poorly named j.u.f.Supplier accepting
log methods, e.g. infoWithSupplier(..) - which avoids overload collision
with existing methods (Yuck!).
3. An adapter from j.u.f.Supplier to log4j.Supplier - this doesn't
seem in any way helpful given the use-sites.
4. log4j.Supplier extends j.u.f.Supplier - this doesn't seem in any
way helpful given the use-sites.
5. Break binary compatibility, since maybe there are other binary
incompatible changes anyway, so it might not be that bad! (and in this
specific case, recompilation will just work without any source code changes)
In the microcosm of this particular issue I don't see a forerunner, but
maybe it's a non-issue if there are other more compelling factors for a
v3 API, then the decision becomes much easier.
On 13/05/2022 23:17, Matt Sicker wrote:
> There’s @Deprecated(forRemoval = true) which can rise different
warnings or errors from a regular deprecated element.
Yes, javac will ultimately raise an error when it encounters an API
element that is terminally (forRemoval = true) deprecated.
-Chris.
On 13/05/2022 23:17, Matt Sicker wrote:
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
