<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">In my development branch there's a file called JAVA8.md with some design notes. I will add more examples to that when I get a chance. Here's a quick contrived example:<br><br></div><div class="gmail_default"><span style="font-family:monospace,monospace">logger.debug("Shipping status change to {} on order {} for customer {}",<br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">    shipment.getStatus(), shipment.getOrderInfo().getId(),<br>    shipment.getOrderInfo().getCustomer().getName());<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Note the multiple layers of indirection: they might have a latency cost. There also might be some cost in the implementation of the <span style="font-family:monospace,monospace">getOrderInfo()</span> or getCustomer() methods. This type of code is common in many real-world codebases. With my code, there are now 3 ways to handle this:<br><br><div class="gmail_default"><div class="gmail_default"><span style="font-family:monospace,monospace">logger.debug("Shipping status change to {} on order {} for customer {}",<br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">    () -> new Object[]{ shipment.getStatus(), shipment.getOrderInfo().getId(),<br>        shipment.getOrderInfo().getCustomer().getName() });<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><span style="font-family:monospace,monospace">logger.debug("Shipping status change to {} on order {} for customer {}",<br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">    () -> shipment.getStatus(), () -> shipment.getOrderInfo().getId(),<br>    () -> shipment.getOrderInfo().getCustomer().getName());<br></span></div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><font face="monospace,monospace">if (logger.isDebugEnabled() {<br></font><div class="gmail_default"><span style="font-family:monospace,monospace">    logger.debug("Shipping status change to {} on order {} for customer {}",<br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">        shipment.getStatus(), shipment.getOrderInfo().getId(),<br>        shipment.getOrderInfo().getCustomer().getName());<br></span></div><font face="monospace,monospace">}<br></font></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">HTH,<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Nathan<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From: Chetan Mehrotra <<a href="mailto:chetan.mehrotra@gmail.com">chetan.mehrotra@gmail.com</a>><br>To: slf4j developers list <<a href="mailto:slf4j-dev@qos.ch">slf4j-dev@qos.ch</a>><br>Cc: <br>Date: Tue, 27 Oct 2015 11:33:20 +0530<br>Subject: Re: [slf4j-dev] Java 8 Support<br>Looks appealing! Do you have any page/wiki which demonstrate intend<br>
usage mode of SLF4J API using JDK 8 features and hence show the<br>
benefits?<br>
Chetan Mehrotra<br>
<br>
<br>
On Tue, Oct 27, 2015 at 11:25 AM, Nathan Green <<a href="mailto:ngreen@inco5.com">ngreen@inco5.com</a>> wrote:<br>
> Greetings,<br>
><br>
> I have a new proposal to implement support for lambdas in Java 8. Not just a<br>
> proposal, but code, documentation, and tests to go with it. It's certainly<br>
> not complete, but I feel it has progressed enough that it is ready for<br>
> public review.<br>
><br>
> What's done:<br>
><br>
> 1. A comprehensive set of default methods have been added to the Logger<br>
> interface. This is the critical change from which everything else flows.<br>
> 2. Javadocs exist on all default methods.<br>
> 3. Every default method has been tested to delegate to the correct virtual<br>
> method. Methods with markers are included in these tests.<br>
> 4. Preliminary testing of default methods with null lambda arguments appear<br>
> correct.<br>
> 5. A suite of integration tests has been created to test out compatibility<br>
> under various runtime scenarios. So far, the new API has been shown to work<br>
> with existing slf4j-simple versions 1.6.6 and 1.7.12 and logback 1.0.1.<br>
> 6. Compatibility with Retrolambda has been verified using JDK 7. It appears<br>
> to be feasible to use bytecode weaving to run lambda-dependent source code<br>
> on versions of Java at least as far back as 5.<br>
><br>
> What's left to do:<br>
><br>
> 1. Review/critique/refine API changes. An API needs time and feedback to<br>
> become good. I believe the general approach I have chosen will work, but the<br>
> specifics may be improved.<br>
> 2. Implement lambdas directly in slf4j-simple to ensure best performance.<br>
> 3. Expand suite of integration tests to ensure maximal compatibility. Make<br>
> method coverage much more thorough.<br>
> 4. Test Retrolambda under various VMs, particularly Android.<br>
> 5. Test performance of lambdas vs. existing approach. I have not had time to<br>
> break out JMH, but I plan on doing so if this proposal gets any traction.<br>
> Even if performance is less than ideal, I would still utilize lambdas in<br>
> production code if the performance tradeoff were acceptable but of course I<br>
> can't know what those tradeoffs are until the tests have been done.<br>
> 6. Create user documentation to explain and demonstrate the new features.<br>
> 7. Other things I probably haven't thought of yet.<br>
> 8. Release SLF4J 1.8.<br>
><br>
> Rationale:<br>
><br>
> Without support for lambdas, SLF4J runs the risk of becoming obsolete.<br>
> Developers on modern Java stacks like compact, clean, idiomatic code, and<br>
> lambdas are becoming a crucial facet of modern design. If SLF4J is to remain<br>
> the logging API of choice, it must evolve to support the systems of the<br>
> future. Further, Java 8's default methods provide the means to compatibly<br>
> evolve an interface, indeed it was designed for situations much like the one<br>
> SLF4J has found itself in. If excellent compatibility can be achieved, now<br>
> is the time to act and make it happen.<br>
><br>
> Where to find it:<br>
><br>
> My Github account has a fork of SLF4J and a separate repository with an<br>
> integration test suite. The API changes live in a (poorly named) branch<br>
> called lambda-for-string-format. I'm more than happy to open a pull request<br>
> for the API changes, and more than happy to accept pull requests for<br>
> integration tests.<br>
><br>
> <a href="https://github.com/nathansgreen/slf4j/tree/lambda-for-string-format" rel="noreferrer" target="_blank">https://github.com/nathansgreen/slf4j/tree/lambda-for-string-format</a><br>
><br>
> <a href="https://github.com/nathansgreen/slf4j-compatibility-suite" rel="noreferrer" target="_blank">https://github.com/nathansgreen/slf4j-compatibility-suite</a><br>
><br>
><br>
> Conclusion:<br>
><br>
> A fully compatible SLF4J (binary, and source with a single caveat) with<br>
> great lambda support appears feasible. The existing proof of concept and<br>
> test suite provide solid evidence that this can be a reality.<br>
><br>
> Respectfully,<br>
><br>
> Nathan Green<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> slf4j-dev mailing list<br>
> <a href="mailto:slf4j-dev@qos.ch">slf4j-dev@qos.ch</a><br>
> <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a><br>
<br><br></blockquote></div></div></div>