Looks appealing! Do you have any page/wiki which demonstrate intend usage mode of SLF4J API using JDK 8 features and hence show the benefits? Chetan Mehrotra
On Tue, Oct 27, 2015 at 11:25 AM, Nathan Green <ngr...@inco5.com> wrote: > 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 _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
