maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <ma...@apache.org>
Subject Re: Investigation on the diffusion of innovation along with java releases
Date Wed, 31 Jul 2019 19:20:37 GMT
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, f.petrulio@virgilio.it.INVALID 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message