Changing API design to accommodate lambda expressions

I am a researcher investigating the changes that Java based APIs had to make to adapt to the introduction of lambda and stream support in Java. What we have seen till now, is that APIs such as JUnit can make large wholesale changes, for example, with the introduction of junit-jupiter-api, the JUnit developers pretty much rewrote the API. On the other hand, the Spring API did not have to make many changes to support functional interfaces. APIs such as Guava used to provide functional support as a workaround, but they standardized their API by removing these "functions" and supported standard Java 8 lambdas. We would like to know, from the API producer or API consumer perspective as to how they perceive the introduction of lambda support in their APIs. It would be nice if you could fill out this survey: https://www.surveygizmo.com/s3/4781913/734bc7d83419 and help us understand this phenomenon better.

Going forward, we want to understand what API design principles need to apply to other APIs which have not made the switch. Furthermore, we want to establish whether after all these years of Java 8's existence, the lambda expressions are truly being used, and why this is not the case. With the data that we have collected from OSS projects, we see that for all of JUnit's development effort, the junit-jupiter-api is not really being used to that large a degree (only 267 projects out of 250,000 maven based projects and 27 out of 243,000 gradle based projects). This calls into question the need for large developer effort, and the ways in which this can be minimized. Also, it puts into perspective the introduction of lamdbas in the java and the (perceived) benefits of having done so.

All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad: