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: logger.debug("Shipping status change to {} on order {} for customer {}", shipment.getStatus(), shipment.getOrderInfo().getId(), shipment.getOrderInfo().getCustomer().getName()); Note the multiple layers of indirection: they might have a latency cost. There also might be some cost in the implementation of the getOrderInfo() 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: logger.debug("Shipping status change to {} on order {} for customer {}", () -> new Object[]{ shipment.getStatus(), shipment.getOrderInfo().getId(), shipment.getOrderInfo().getCustomer().getName() }); logger.debug("Shipping status change to {} on order {} for customer {}", () -> shipment.getStatus(), () -> shipment.getOrderInfo().getId(), () -> shipment.getOrderInfo().getCustomer().getName()); if (logger.isDebugEnabled() { logger.debug("Shipping status change to {} on order {} for customer {}", shipment.getStatus(), shipment.getOrderInfo().getId(), shipment.getOrderInfo().getCustomer().getName()); } HTH, Nathan From: Chetan Mehrotra <chetan.mehrotra@gmail.com>
To: slf4j developers list <slf4j-dev@qos.ch> Cc: Date: Tue, 27 Oct 2015 11:33:20 +0530 Subject: Re: [slf4j-dev] Java 8 Support 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 <ngreen@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