[slf4j-dev] Java 8 Support

[Nathan Green]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20151027/1efce57b/attachment.html>