> On Dec 16, 2019, at 9:42 AM, Raman Gupta <rocketra...@gmail.com> wrote:
>
> 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
Thanks for the input.
The current log4j 2 API already supports lambdas. Are you proposing that we do
something different? What would that look like?
FWIW, the idea that we would have to bridge the Log4j 2 API to a Log4j 3
implementation doesn’t make sense to me. I would think that would annoy users.
The Log4j 3 implementation needs to work with the Log4j 2 API. The problem
Gary is highlighting is that having both the jars for the Log4j 2 API and Log4j
3 API would mean the package structure would need to be different between them.
Instead, I would prefer that the Log4j 3 API be backward compatible with the
Log4j 2 API.
Ralph
