October 2015 - slf4j-dev - mailman3.qos.ch

Re: [slf4j-dev] Java 8 Support
by Nathan Green 27 Oct '15

27 Oct '15

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(a)gmail.com> > To: slf4j developers list <slf4j-dev(a)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(a)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(a)qos.ch > > http://mailman.qos.ch/mailman/listinfo/slf4j-dev > > >

1 0

Java 8 Support
by Nathan Green 27 Oct '15

27 Oct '15

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

2 1

[JIRA] (SLF4J-324) Initializing org.slf4j.helpers.Util fails if SecurityManager denies "createSecurityManager"
by Trejkaz (JIRA) 19 Oct '15

19 Oct '15

1 0

[JIRA] (SLF4J-324) Initializing org.slf4j.helpers.Util fails if SecurityManager denies "createSecurityManager"
by Alexander Dorokhine (JIRA) 18 Oct '15

18 Oct '15

1 0

[JIRA] (SLF4J-324) Initializing org.slf4j.helpers.Util fails if SecurityManager denies "createSecurityManager"
by Alexander Dorokhine (JIRA) 18 Oct '15

18 Oct '15

1 0

[JIRA] (SLF4J-181) juli-over-slf4j module
by wyf (JIRA) 18 Oct '15

18 Oct '15

1 0

[JIRA] (SLF4J-324) Initializing org.slf4j.helpers.Util fails if SecurityManager denies "createSecurityManager"
by Ceki Gulcu (JIRA) 16 Oct '15

16 Oct '15

1 0

[JIRA] (SLF4J-324) Initializing org.slf4j.helpers.Util fails if SecurityManager denies "createSecurityManager"
by Ceki Gulcu (JIRA) 16 Oct '15

16 Oct '15

1 0

[qos-ch/slf4j] 52fcbb: minor update to news.html
by Ceki Gulcu 16 Oct '15

16 Oct '15

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 52fcbbe855fbd89942bf0cb450301471851b386f https://github.com/qos-ch/slf4j/commit/52fcbbe855fbd89942bf0cb450301471851b… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2015-10-16 (Fri, 16 Oct 2015) Changed paths: M slf4j-site/src/site/pages/news.html Log Message: ----------- minor update to news.html

1 0

[qos-ch/slf4j] 572dab: less in MANIFEST.MF
by Ceki Gulcu 16 Oct '15

16 Oct '15

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: 572dabfa7c0a7d7bb2e381bda6e2ad92b086bb6b https://github.com/qos-ch/slf4j/commit/572dabfa7c0a7d7bb2e381bda6e2ad92b086… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2015-10-16 (Fri, 16 Oct 2015) Changed paths: M pom.xml M slf4j-site/src/site/pages/news.html Log Message: ----------- less in MANIFEST.MF

1 0