The compiler already can’t tell the different between MessageSupplier and Supplier<Message> where used (this was a problem with Spark’s API when Java 8 came out as well).
On Mon, Dec 16, 2019 at 12:36 Ralph Goers <[email protected]> wrote: > > > > On Dec 16, 2019, at 11:13 AM, Gary Gregory <[email protected]> > wrote: > > > > From the 10,000 ft level, within one app: > > > > - Log4j 2 configures itself by finding a log4j2.xml file. > > - Log4j 3 configures itself by finding a log4j3.xml file. > > - Both can co-exist happily > > - The bridge exercise can be done separately. > > No, no, no. Nobody wants more than one logging implementation active. > Nobody. And so far we haven’t talked about changing the logging > configuration syntax, nor do I see any reason to do that. So there is no > need for a log4j3.xml. > > If we go down that road you will just piss off users and have them switch > to other logging choices. > > > > > > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to > > appenders at least, I know I've removed deprecated methods, not sure > about > > the log4j-api module. > > There is a big difference between the API and implementation. While we > should make every attempt to allow Plugins written for 2.x to continue to > work against 3.x we can require that plugins may have to be modified to > compile against 3.x. That is the route I have been taking with all the > changes I have made, including the changes I made to the plugin system > itself. Of course, we will need to verify that 2.x plugins actually run > with 3.x and fix any bugs we find. > > > > > > IMO: A major version let's us break things and provide a better API, > > otherwise, we can keep on the 2.x branch. > > Yes, we can improve the API, but code compiled against 2.x still needs to > run against 3.x. While we can break things inside the implementation we > should avoid breaking the API. Otherwise our users will hate us. You have > to remember how much code there is out there that uses the API. If you > make it incompatible you are just giving users a reason to use SLF4J. > > If you want an improved API you can create a new interface, but users > probably won’t love that either. > > > > > > For example, this API and all like it should be gone from 3.0: > > > > org.apache.logging.log4j.Logger.debug(Marker, > > org.apache.logging.log4j.util.Supplier<?>) > > > > and replaced with: > > > > org.apache.logging.log4j.Logger.debug(Marker, > > java.util.function.Supplier<T><?>) > > Why? A user coding a Lambda doesn’t care what the underlying class is. > Only people actually coding to that interface (nobody?) would care. > > > > > > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, should > be > > replaced by java.util.function.Supplier in 3.0. > > -1 unless you can give me some benefit to doing that besides - “it is the > standard Java interface”. > > > > > > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, add > > java.util.function.Supplier version of all methods and _deprecate_ all > > org.apache.logging.log4j.util.Supplier methods. > > Umm, I am doubtful you can do that. I’d be surprised if the compiler can > figure out which one to use when it is compiling a lambda. > > > > > We can also explore other kinds of logging APIs. One maybe goofy example > > was my attempt a long time ago maybe even still in some branch of having > > log methods on levels so you can say "Level.DEBUG.log(levellogger, ...)" > > which I did to avoid the explosion of methods on Logger whenever you want > > to add a new API (you need to duplicate it for debug, info, warn, and so > > on.) > > We just added that in 2.13.0. Did you miss that? > > Ralph > -- Matt Sicker <[email protected]>
