Greetings, 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.
What's done: 1. A comprehensive set of default methods have been added to the Logger interface. This is the critical change from which everything else flows. 2. Javadocs exist on all default methods. 3. Every default method has been tested to delegate to the correct virtual method. Methods with markers are included in these tests. 4. Preliminary testing of default methods with null lambda arguments appear correct. 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. 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. What's left to do: 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. 2. Implement lambdas directly in slf4j-simple to ensure best performance. 3. Expand suite of integration tests to ensure maximal compatibility. Make method coverage much more thorough. 4. Test Retrolambda under various VMs, particularly Android. 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. 6. Create user documentation to explain and demonstrate the new features. 7. Other things I probably haven't thought of yet. 8. Release SLF4J 1.8. Rationale: 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. Where to find it: 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 *lambda-for-string-format*. 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. https://github.com/nathansgreen/slf4j/tree/lambda-for-string-format https://github.com/nathansgreen/slf4j-compatibility-suite Conclusion: 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. Respectfully, Nathan Green
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
