[slf4j-dev] Java 8 Support

[Chetan Mehrotra]

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 at 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 at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev