[slf4j-dev] Java 8 Support

Tue Oct 27 13:42:01 UTC 2015

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 at gmail.com>
> To: slf4j developers list <slf4j-dev at 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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20151027/6a294f0d/attachment.html>