Hi Fernando, You ask interesting questions, and the following is of course just my opinion. But I believe it has a lot to do with SWE principles.
When you’re doing engineering, as opposed to research, your software product may have literally millions of people depending on it to work well and predictably. We also know, from SWE studies, that writing new code inevitably introduces new bugs. Thus, a key SWE principle is (sorry for the American idiom, but it’s appropriate here, I think): “If it ain’t broke, don’t fix it!”. No responsible SW engineer or SW engineering manager would undertake a rewrite of known-good APIs to use new but backward-compatible versions of Java. There’s no need, since there’s no great increase in performance or maintainability. And it would introduce new errors and bugs. In production environments, you’ll see adoption of the new language features only where: - in existing code, there is a major improvement in performance or maintainability to be gained, worth the anticipated cost of new bug/fix cycles; or - in new code for new application features, the people writing that code perceive an increase in ease of development (or the aforementioned performance or maintainability) by using the new language features. BTW, this is predicated on the fact that Java 11 is (almost) 100% backward compatible with Java 8. If there were incompatibilities in the language, such that the old application APIs become buggy or have changed semantics, then they may perforce be rewritten in the new language version. But it would create howling complaints and resistance, and greatly impede the adoption of the new language version. As an example, look at the duality induced between Python 2 and 3. I think Python 3 is way better, as a language, then Python 2, but the fact that it’s incompatible and therefore may in many cases require rewriting application code (even though in pretty simple ways), means that there has not been a simple transition to the newer language version. The Java insistence on general backward compatibility has allowed most Java shops to progress along the sequence of versions, reluctantly perhaps, and not as frequently as the new versions are offered, but with some regularity and without undue pain. But with that backward compatibility, there’s no reason to expect existing APIs to be rewritten, as explained above. Hope this helps, —Matt ————————— Open Source Technologies @ Siri `This is not a contribution` On Jul 31, 2019, at 7:23 AM, [email protected] 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 maven-plugin-api, maven-core, maven-artifact, and maven-model’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 maven-plugin-api, maven-core, maven-artifact, and maven-model did not introduce compatibility with Java 8+ features, including Functional Interfaces and Lambda Expression. We would like to better understand as to why these 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. [photo-logo] Fernando Petrulio Ph.D. Student University of Zurich UZH Department of Informatics [linkedin] https://www.linkedin.com/in/fernando-petrulio --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
