<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">Ceki,</span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">SLF4J has methods that take discrete parameters so that it can avoid constructing the LoggingEvent if it does’t need to. This kind of turns that upside down. That said, Lambdas create an object that contains the expensive logic to execute, without executing that logic until necessary. Typically the cost of creating the Lambda objects is insignificant. Log4j 2 already supports Lambdas while still only requiring Java 7 - we just use our own Supplier interface.</span><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"> </span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">I am not sure I see how what you are proposing here correlates at all to what using lambda expressions achieves. In your proposal the user has to construct the LoggingEvent before calling the log method, which implies that the whole thing needs to be wrapped in an if (logger.isDebugEnabled()) block. Lambdas free you from that.</span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">OTOH, it was proposed to you years ago that SLF4J accept Messages [1] - as Log4j 2 does now. I believe this yields more gains than what one would get with your proposal. I think exposing a LoggingEvent that includes the Marker and Level is a bad idea. While the Message interface allows for users to log complex objects, it does so by only solving for that problem and does not introduce fields that really have nothing to do with the message content being delivered.</span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">Although a bit off topic, I should point out that if SLF4J provided an AbstractLogger class that the impact of adding new methods to the Logger interface would pretty much be a non-issue. Most of the time the class extending AbstractLogger wouldn’t need to change. Currently the Log4j 2 API has 192 methods. If AbstractLogger is extended only 7 methods need to be implemented.</span><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"> </span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">Ralph</span><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><br class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);"><span class="" style="color: rgb(51, 51, 51); background-color: rgb(253, 253, 253);">[1] <a href="http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html" class="">http://slf4j.42922.n3.nabble.com/Benefits-of-Message-objects-td3316674.html</a></span></body></html>