<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Greetings,<br><br>I have a new proposal to implement support for lambdas in Java 8. Not just a proposal, but code, documentation, and tests to go with it. It's certainly not complete, but I feel it has progressed enough that it is ready for public review.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">What's done:<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">1. A comprehensive set of default methods have been added to the Logger interface. This is the critical change from which everything else flows.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. Javadocs exist on all default methods.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3. Every default method has been tested to delegate to the correct virtual method. Methods with markers are included in these tests.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">4. Preliminary testing of default methods with null lambda arguments appear correct.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">5. A suite of integration tests has been created to test out compatibility under various runtime scenarios. So far, the new API has been shown to work with existing slf4j-simple versions 1.6.6 and 1.7.12 and logback 1.0.1.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">6. Compatibility with Retrolambda has been verified using JDK 7. It appears to be feasible to use bytecode weaving to run lambda-dependent source code on versions of Java at least as far back as 5.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">What's left to do:<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">1. Review/critique/refine API changes. An API needs time and feedback to become good. I believe the general approach I have chosen will work, but the specifics may be improved.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. Implement lambdas directly in slf4j-simple to ensure best performance.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3. Expand suite of integration tests to ensure maximal compatibility. Make method coverage much more thorough.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">4. Test Retrolambda under various VMs, particularly Android.<br>5. Test performance of lambdas vs. existing approach. I have not had time to break out JMH, but I plan on doing so if this proposal gets any traction. Even if performance is less than ideal, I would still utilize lambdas in production code if the performance tradeoff were acceptable but of course I can't know what those tradeoffs are until the tests have been done.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">6. Create user documentation to explain and demonstrate the new features.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">7. Other things I probably haven't thought of yet.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">8. Release SLF4J 1.8.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Rationale:<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Without support for lambdas, SLF4J runs the risk of becoming obsolete. Developers on modern Java stacks like compact, clean, idiomatic code, and lambdas are becoming a crucial facet of modern design. If SLF4J is to remain the logging API of choice, it must evolve to support the systems of the future. Further, Java 8's default methods provide the means to compatibly evolve an interface, indeed it was designed for situations much like the one SLF4J has found itself in. If excellent compatibility can be achieved, now is the time to act and make it happen.<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Where to find it:<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">My Github account has a fork of SLF4J and a separate repository with an integration test suite. The API changes live in a (poorly named) branch called <i>lambda-for-string-format</i>. I'm more than happy to open a pull request for the API changes, and more than happy to accept pull requests for integration tests.<br><br><a href="https://github.com/nathansgreen/slf4j/tree/lambda-for-string-format">https://github.com/nathansgreen/slf4j/tree/lambda-for-string-format</a><br><br><a href="https://github.com/nathansgreen/slf4j-compatibility-suite">https://github.com/nathansgreen/slf4j-compatibility-suite</a><br><br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Conclusion:<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">A fully compatible SLF4J (binary, and source with a single caveat) with great lambda support appears feasible. The existing proof of concept and test suite provide solid evidence that this can be a reality.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Respectfully,<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Nathan Green<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div>