If there are API incompatibilities, an slf4j-like 2.x api bridge to 3.x would probably be the way to go.
Its been a while since I looked at it, but IIRC, while implementing the Kotlin logger (https://logging.apache.org/log4j/kotlin/), I did note some things that it would be nice to change in the API -- see https://github.com/apache/logging-log4j-kotlin/blob/master/log4j-api-kotlin/src/main/kotlin/org/apache/logging/log4j/kotlin/KotlinLogger.kt#L51-L64. That being said, to make a wider point, if 3.0 is gonna by JDK11+, we could consider promoting lambda-based logging, like the Kotlin logger does, as a first-class log4j3 API. The advantage of a lambda-based logger is no more need for callers to do if-logger-level-enabled checks or to use the messy parameterized methods. Regards, Raman On Mon, Dec 16, 2019 at 10:17 AM Ralph Goers <[email protected]> wrote: > > > > > On Dec 16, 2019, at 7:01 AM, Gary Gregory <[email protected]> wrote: > > > > On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <[email protected] > > <mailto:[email protected]>> > > wrote: > > > >> > >> > >>> On Dec 15, 2019, at 2:44 PM, Gary Gregory <[email protected]> > >> wrote: > >>> > >>> All good thoughts. > >>> > >>> I suspect that now that 2.x is on Java 8 there are some clean ups we will > >>> want to do. What comes to mind immediately is deprecating our functional > >>> interfaces in favor of the ones in java.util.function. Then we can drop > >> our > >>> custom functional interfaces in the 3.0 branch (if that did not already > >>> happen.) > >> > >> Although I am not opposed, is there any benefit to that? It just adds more > >> binary incompatibilities. Although some are necessary I’d like to keep the > >> upgrade from 2.x to 3.0 as easy as possible. > >> > > > > By definition 3.0 is going to be binary incompatible with 2.x, so I am not > > worried about how much different it will be. Log4j 3 will have to be > > repackaged so that it can live in the same class loader as Log4j 2, > > otherwise, it will be a giant headache for people (like me) that live in > > large stacks with dependencies they cannot control that use all sorts of > > stuff. > > > Umm. What you are describing sounds like a nightmare. Having multiple > incompatible Log4j versions would mean we would have to build a bridge > between the two so that users of the 2.x API can route to the 3.x > implementation. If the APIs are the same then that wouldn’t be necessary. > It has been so long that I have forgotten if we have really made the API > incompatible. > > Ralph
