Fwd: investigation on the diffusion of innovation along with java releases
Dear Developers, we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected SLF4J’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings. Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization. Our analysis showed that though SLF4J 2.0 did not explicitly introduce support for functional interfaces (e.g. by using the @FunctionalInterface annotation). We noticed that the API does provide compatibility with Java 8+ features, including lambda expressions (since the API’s build platform is now on JDK 1.8). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API. In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this? How did you and your team tackle the choice to change the version of Java supported? Which factors did you take into account when doing this? Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with? Why were no explicit changes made to the interface to support lambda expressions? Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported? We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know! Kind Regards, Fernando Petrulio. -- Fernando Petrulio Ph.D. Student - University of Zurich UZH Department of Informatics fpetrulio@ifi.uzh.ch
Hello Fernando, As a widely used API, the challenge in changing SLF4J is preserving 100% compatibility. This was achieved by using Java 8 default implementation feature (widely used in the Logger interface). Given that SLF4J does not actually contain much code, we did not make use of lambdas internally. However, this will probably change as changes are made to the code. Best regards, -- Ceki On 30/07/2019 09:45, Fernando Petrulio wrote:
Dear Developers,
we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected SLF4J’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings.
Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization. Our analysis showed that though SLF4J 2.0 did not explicitly introduce support for functional interfaces (e.g. by using the @FunctionalInterface annotation). We noticed that the API does provide compatibility with Java 8+ features, including lambda expressions (since the API’s build platform is now on JDK 1.8). We would like to better understand as to why no major change was necessitated to facilitate the usage of lambda expressions with the API.
In most cases, developers choose to move to new releases to satisfy particular dependency requirements, to take advantage of new Java features (like streams and functional interfaces in the case of Java 8), or just to standardize their implementation to align the API with the Java JDK API. Can you provide us with more information about this? How did you and your team tackle the choice to change the version of Java supported? Which factors did you take into account when doing this? Are there any documented sources (e.g. Jira tickets, or issue tracker issues) about that discussion you can provide us with? Why were no explicit changes made to the interface to support lambda expressions? Are there any future plans in place to make larger changes to the API such that lambda expressions would be supported?
We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know!
Kind Regards, Fernando Petrulio.
Hi Ceki, Thank you for the response! I am a researcher working with Fernando on this and had some follow up questions. The question we want to answer centers around the SLF4J interface itself. There has been this issue on the SLF4J API for a while: https://jira.qos.ch/browse/SLF4J-371. There appear to be a few workarounds that developers have implemented to provide a fluent interface with SLF4J. Even, Log4J changed its interface to take a lambda expression as a param and allow for lazy evaluation of the expression, thereby providing the client with a performance benefit. I see that the discussion on this has been more active recently, but is there any reason as to why SLF4J did not make a similar change? Are there concrete plans to introduce this change soon? Regards, Anand Sawant. -- Sent from: http://slf4j.42922.n3.nabble.com/slf4j-dev-f41812.html
Hello Anand, The issue of lambdas is handled by the fluent API introduced in SLF4J version 2.0. See https://www.slf4j.org/manual.html#fluent Comments welcome, -- Ceki On 12/08/2019 16:10, anandsaw wrote:
Hi Ceki,
Thank you for the response! I am a researcher working with Fernando on this and had some follow up questions.
The question we want to answer centers around the SLF4J interface itself. There has been this issue on the SLF4J API for a while: https://jira.qos.ch/browse/SLF4J-371. There appear to be a few workarounds that developers have implemented to provide a fluent interface with SLF4J. Even, Log4J changed its interface to take a lambda expression as a param and allow for lazy evaluation of the expression, thereby providing the client with a performance benefit. I see that the discussion on this has been more active recently, but is there any reason as to why SLF4J did not make a similar change? Are there concrete plans to introduce this change soon?
Regards, Anand Sawant.
Hi Ceki, Thank you again for the response and pointing us to version 2.0.0. We appear to have not looked at that one (as it was publicly released after our initial manual analysis). This would imply that in our investigation SLF4J is one of the APIs that has made a change. Just so that we can document this correctly, could you please elaborate on why this change was made? And what the process was? And why this has taken time since the initial issue? Thank you again for being responsive, this quite the help for us! Regards, Anand Sawant. -- Sent from: http://slf4j.42922.n3.nabble.com/slf4j-dev-f41812.html
The introduction of lambdas was made in conjunction with another even more profound change, namely the fluent-api. The fluent api makes the introduction of changes in the Logger class both cheaper and avoids creating a combinatorial explosion. It took time to commit to this change as once released, such client visible changes to the API cannot be taken back. On 12/08/2019 17:04, anandsaw wrote:
Hi Ceki,
Thank you again for the response and pointing us to version 2.0.0. We appear to have not looked at that one (as it was publicly released after our initial manual analysis). This would imply that in our investigation SLF4J is one of the APIs that has made a change. Just so that we can document this correctly, could you please elaborate on why this change was made? And what the process was? And why this has taken time since the initial issue?
Thank you again for being responsive, this quite the help for us!
Regards, Anand Sawant.
-- Sent from: http://slf4j.42922.n3.nabble.com/slf4j-dev-f41812.html _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
participants (3)
-
anandsaw -
Ceki Gülcü -
Fernando Petrulio