Investigation on the diffusion of innovation along with java releases
20 views
Skip to first unread message
Fernando Petrulio
Jul 31, 2019, 11:54:25 AM7/31/19
to Hamcrest Developers
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 hamcrest-core, hamcrest-all, hamcrest-library, and java-hamcrest’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 hamcrest-core, hamcrest-all, hamcrest-library, and java-hamcrest did not introduce compatibility with Java 8+ features, including Functional Interfaces and Lambda Expression. We would like to better understand as to why the APIs do not support newer Java language versions and their features.
Our investigation showed us that in most cases API producers do not migrate their APIs to newer Java Releases. Despite this, the API remains to be widely used by consumers on GitHub. Can you provide us with more information on this phenomenon?
Did you and your team ever discuss the migration to new Java releases? If so, what did this discussion entail?
What is the reason behind not migrating to a newer Java version?
Did the introduction of new language features such as lambda expressions influence your decision in any way?
Does your API plan on introducing support for lambda expressions in the future?
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.
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 hamcrest-core, hamcrest-all, hamcrest-library, and java-hamcrest’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 hamcrest-core, hamcrest-all, hamcrest-library, and java-hamcrest did not introduce compatibility with Java 8+ features, including Functional Interfaces and Lambda Expression. We would like to better understand as to why the APIs do not support newer Java language versions and their features.
Our investigation showed us that in most cases API producers do not migrate their APIs to newer Java Releases. Despite this, the API remains to be widely used by consumers on GitHub. Can you provide us with more information on this phenomenon?
Did you and your team ever discuss the migration to new Java releases? If so, what did this discussion entail?
What is the reason behind not migrating to a newer Java version?
Did the introduction of new language features such as lambda expressions influence your decision in any way?
Does your API plan on introducing support for lambda expressions in the future?
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.
John Patrick
Jul 31, 2019, 12:10:40 PM7/31/19
to hamcre...@googlegroups.com
From your research can you identify where it would actually add extra
value apart, from mass refactoring just for the sake of it. Personally
I don't believe it will add much benefit vs the effort involved.
If you think about the 90% of use cases of how hamcrest is used, it is
similar to this pattern.
org.junit.jupiter.api.Assertions.assertAll("description",
() -> org.hamcrest.MatcherAssert.assertThat("message", new
Object(), org.hamcrest.core.Is.is(org.hamcrest.core.IsNull.notNullValue()))
);
So as long as the testing framework that hamcrest is used within
supports lambdas, then hamcrest is used within lambdas. Hamcrest
internally doesn't need to use lambdas.
Hamcrest should probably switch to a multi java version support, but
changing the default required java to a newer version will break
support and compatibility for consumers that might not be able to
upgrade yet.
Yes long term Hamcrest should bump to java 8, then java 11.
John
Hamcrest Contributer
> --
> You received this message because you are subscribed to the Google Groups "Hamcrest Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/db21aaff-2c6d-400e-9258-c6440dff8205%40googlegroups.com.
value apart, from mass refactoring just for the sake of it. Personally
I don't believe it will add much benefit vs the effort involved.
If you think about the 90% of use cases of how hamcrest is used, it is
similar to this pattern.
org.junit.jupiter.api.Assertions.assertAll("description",
() -> org.hamcrest.MatcherAssert.assertThat("message", new
Object(), org.hamcrest.core.Is.is(org.hamcrest.core.IsNull.notNullValue()))
);
So as long as the testing framework that hamcrest is used within
supports lambdas, then hamcrest is used within lambdas. Hamcrest
internally doesn't need to use lambdas.
Hamcrest should probably switch to a multi java version support, but
changing the default required java to a newer version will break
support and compatibility for consumers that might not be able to
upgrade yet.
Yes long term Hamcrest should bump to java 8, then java 11.
John
Hamcrest Contributer
> You received this message because you are subscribed to the Google Groups "Hamcrest Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/db21aaff-2c6d-400e-9258-c6440dff8205%40googlegroups.com.
Anand Sawant
Aug 12, 2019, 9:38:17 AM8/12/19
to Hamcrest Developers
Thank you for the reply John! I am a researcher working with Fernando. You raise a valid point about identifying the need about what parts could be refactored to use lambdas. During our investigation, we identified several reasons to change the API, that include: improving the readability of code, preserving functional purity or improving performance. We found that for one of these reasons an API would actually migrate to Java 8+ and adopt lambdas in their code (eg. Spring framework or JUnit). The larger question is, whether Hamcrest would benefit in any way from changing the interface to accommodate lambdas? Or is this simply unnecessary given that clients using Java 8+ can already write their code in a more functional manner (as illustrated in your example) without Hamcrest being Java 8 compliant?
> To unsubscribe from this group and stop receiving emails from it, send an email to hamcre...@googlegroups.com.
David Wilson
Aug 12, 2019, 9:49:28 AM8/12/19
to hamcre...@googlegroups.com
Hi Anand,
Would you please clarify?
What do you mean by Java 8 compliant?
I am not aware of any difficultly compiling Java 8 test code with the Hamcrest library.
To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/bd3f957f-acec-449f-8fd5-7c0445d92aa6%40googlegroups.com.
Anand Sawant
Aug 12, 2019, 10:04:01 AM8/12/19
to Hamcrest Developers
Hi David,
My go to example on this is JUnit, which pretty much rewrote the entire API to add explicit support for lambdas and to take functional interfaces as params (using the @Functionalnterface annotation). Maybe Java 8+ compliant is the wrong phrasing, but for example, would Hamcrest actually allow for lazy evaluation of params using a lambda?
Regards,
Anand Sawant.
To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/bd3f957f-acec-449f-8fd5-7c0445d92aa6%40googlegroups.com.
--
John Patrick
Aug 20, 2019, 5:11:41 PM8/20/19
to hamcre...@googlegroups.com
Like i said 90% of my usage of hamcrest is within a junit 5 lambda, so
are you suggesting a lambda within a lambda like xxx and yyy in the
example below?
assertAll("message",
() -> assertThat("message", () -> xxx, is(equalTo(() -> yyy)))
);
I think it would just make the code harder to read.
Junit 5 adding lambda's enabled all downstream frameworks from taking
advantage of lambdas for testing but don't have to support it
themselves.
Their might be usage cases for hamcrest to support lambda's but i
can't think of any actual use cases or places where i've thought i'm
lacking anything because hamcrest doesn't support lambda's. Maybe if
your suggest some actual examples of testing code that would benefit
it might be helpful... as i'm really trying to think of examples and
use cases that would back development to add lambdas.
Views of a Hamcrest User, that has switched all asserts to hamcrest and junit5.
John
> To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/899e83b3-ef9e-4d7c-a292-23cc323626ec%40googlegroups.com.
are you suggesting a lambda within a lambda like xxx and yyy in the
example below?
assertAll("message",
() -> assertThat("message", () -> xxx, is(equalTo(() -> yyy)))
);
I think it would just make the code harder to read.
Junit 5 adding lambda's enabled all downstream frameworks from taking
advantage of lambdas for testing but don't have to support it
themselves.
Their might be usage cases for hamcrest to support lambda's but i
can't think of any actual use cases or places where i've thought i'm
lacking anything because hamcrest doesn't support lambda's. Maybe if
your suggest some actual examples of testing code that would benefit
it might be helpful... as i'm really trying to think of examples and
use cases that would back development to add lambdas.
Views of a Hamcrest User, that has switched all asserts to hamcrest and junit5.
John
> To view this discussion on the web visit https://groups.google.com/d/msgid/hamcrest-dev/899e83b3-ef9e-4d7c-a292-23cc323626ec%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages