Well, SLF4J recently changed the binding mechanism with 1.8 in order to comply with Java 9. It isn’t likely to do it again any time soon.
What we would “solve” is that now it is log4j-api -> log4j-to-slf4j -> slf4j-api -> logging implementation. With this change it would be log4j-api -> log4j-slf4j-binding -> logging implementation. I see 2 advantages to this: 1. It would be harder to say that the log4j-api isn’t appropriate to be the logging API since the binding to SLF4J implementations would be very light. 2. The code path to get to an SLF4J implementation would be shorter. To be honest, item 1 is the one I find more appealing. It reminds me of how OS/2’s support for Windows was not what people really wanted vs the way Windows NT handled it. Ralph > Begin forwarded message: > > From: Remko Popma <[email protected]> > Subject: Re: log4j-to-slf4j > Date: September 24, 2017 at 4:27:59 PM MST > To: [email protected] > Reply-To: [email protected] > > That's certainly possible. > The trade off is that we'd need to track the SLF4J binding mechanism and > update our implementation when this binding mechanism changes. > > What problem are we trying to solve? > > Remko > >> On Sep 25, 2017, at 7:16, Ralph Goers <[email protected]> wrote: >> >> In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is >> strikes me that log4j-to-slf4j is binding to the SLF4J API while >> log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using >> SLF4J’s binding mechanism. So it seems to me that instead of having >> log4j-to-slf4j call the SLF4J API we ought to be able to have it call the >> SLF4J bindings and completely bypass SLF4J itself. Some user’s might find >> this more palatable as it would remove one layer between the Log4j API and >> whatever logging implementation the user chose. >> >> Thoughts? >> >> Ralph >
