You broke my code: understanding the motivations for breaking changes in APIs

Brito, Aline; Valente, M.; Xavier, Laerte; Hora, André

doi:10.1007/s10664-019-09756-z

Cited by 29 publications

(27 citation statements)

References 48 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…They identified five reasons: library simplification, refactoring, bug fixes, dependency changes, project policy. This study was later extended by Brito et al (A. Brito et al 2020) where they reported that 47% of breaking changes are due to refactorings. These results can be complemented by the previous study by Dig and Johnson (Dig & Johnson 2006) who analysed breaking changes in five Java systems and discovered that 81-100% of them are caused by refactorings.…”

Section: Related Workmentioning

confidence: 90%

Deprewriter: On the fly rewriting method deprecations.

Ducasse¹,

Polito²,

Zaitsev³

et al. 2022

JOT

View full text Add to dashboard Cite

Deprecations are a common way to indicate that a given feature or API will not be available in subsequent versions of a library or framework. While raising deprecation warnings lets developers of libraries evolve their APIs, the developers of client applications often have to manually rewrite their applications to adapt to the deprecation (removal, new APIs. . . ). Some may use static analysis tools to support the rewriting. However, dynamically-typed languages or the use of reflective features often produce incorrect rewrite candidates. This is a costly activity that can lead to bug introductions.In this article, we present a method deprecation approach and a tool called DEPREWRITER that can automatically rewrite the callers of deprecated methods during program execution. Clients of a deprecated API execute their program and associated tests, and DEPREWRITER dynamically rewrites the source code of methods that called a deprecated API to use the new API.The implementation of DEPREWRITER is based on dynamic program transformation: when a deprecated method is executed, a program transformation engine rewrites and recompiles the caller's code before continuing the execution.The approach presented in this article has been developed by the Pharo consortium. Since 2016, DEPREWRITER is used in production in multiple distributions of the Pharo programming language: Pharo 6, 7, 8, and 9 alpha. This article presents and validates this approach.The validation is done in two steps: first with an analysis of deprecations available in Pharo 8 and second with an open survey of software developers about DEPREWRITER. We studied 367 Pharo 8 deprecations, among which we analyzed the 218 rewriting deprecations that use transformation rules. We identified the validity conditions and reported defects to the community. We also proposed 33 transformation rules to be added to the non-rewriting deprecations. Both contributions were accepted into Pharo 9 alpha. We classified the rules and identified possible points of improvement. In addition, we performed a user survey and collected information from 46 software developers: some of them used existing DEPREWRITER' rules and executed them on their code, others used DEPREWRITER to create rewriting deprecations, and finally, some were not aware of DEPREWRITER. 28 of 46 developers (60%) reported that the rewriting deprecations helped them, while 10 stated the inverse and 8 were uncertain.After discussing the current implementation, we sketch possible implementations for other languages than Pharo, showing that the approach is general enough to be applied to other languages.

show abstract

Section: Related Workmentioning

confidence: 90%

Deprewriter: On the fly rewriting method deprecations.

Ducasse¹,

Polito²,

Zaitsev³

et al. 2022

JOT

View full text Add to dashboard Cite

show abstract

“…5) API Evolution: APIs evolve over time, and the changes often break the client developers' code (e.g. [13]). Generally, the most common API breaking changes are due to refactorings [14].…”

Section: Software Engineering Challengesmentioning

confidence: 99%

Challenges and Governance Solutions for Data Science Services based on Open Data and APIs

Joutsenlahti¹,

Lehtonen²,

Raatikainen

et al. 2021

2021 IEEE/ACM 1st Workshop on AI Engineering - Software Engineering for AI (WAIN)

View full text Add to dashboard Cite

Increasingly common open data and open application programming interfaces (APIs) together with the progress of data science -such as artificial intelligence (AI) and especially machine learning (ML) -create opportunities to build novel services by combining data from different sources. In this experience report, we describe our firsthand experiences on open data and in the domain of marine traffic in Finland and Sweden and identified technological opportunities for novel services. We enumerate five challenges that we have encountered with the application of open data: relevant data, historical data, licensing, runtime quality, and API evolution. These challenges affect both business model and technical implementation. We discuss how these challenges could be alleviated by better governance practices for provided open APIs and data.

show abstract

“…Introducing and removing new primitive algorithms suggest that there should exist CrySL rules for every version of that API that introduces a change. Using a customized version of apidiff, we also investigated breaking changes [6,8,49], that is, changes between consecutive releases of an API that break the client code. Next, we execute queries into this database and export the results to CSV files to analyze and understand the evolution of crypto APIs.…”

Section: Study Settingsmentioning

confidence: 99%

“…In the last Bouncy Castle release considered in our analysis (release 1.60), we identified more than 140 primitive implementations, among them 45 implementations of the BlockCipher interface. 6 Block cipher (45), message (b)…”

Section: Rq3: Variability Due To the Evolution Of The Apismentioning

confidence: 99%

Dealing with Variability in API Misuse Specification

Bonifacio,

Krüger,

Narasimhan

et al. 2021

Preprint

View full text Add to dashboard Cite

APIs are the primary mechanism for developers to gain access to externally defined services and tools. However, previous research has revealed API misuses that violate the contract of APIs to be prevalent. Such misuses can have harmful consequences, especially in the context of cryptographic libraries. Various API-misuse detectors have been proposed to address this issue-including CogniCrypt, one of the most versatile of such detectors and that uses a language (CrySL) to specify cryptographic API usage contracts. Nonetheless, existing approaches to detect API misuse had not been designed for systematic reuse, ignoring the fact that different versions of a library, different versions of a platform, and different recommendations/guidelines might introduce variability in the correct usage of an API. Yet, little is known about how such variability impacts the specification of the correct API usage. This paper investigates this question by analyzing the impact of various sources of variability on widely used Java cryptographic libraries (including JCA/JCE, Bouncy Castle, and Google Tink). The results of our investigation show that sources of variability like new versions of the API and security standards significantly impact the specifications. We then use the insights gained from our investigation to motivate an extension to the CrySL language (named MetaCrySL), which builds on meta-programming concepts. We evaluate MetaCrySL by specifying usage rules for a family of Android versions and illustrate that MetaCrySL can model all forms of variability we identified and drastically reduce the size of a family of specifications for the correct usage of cryptographic APIs.2012 ACM Subject Classification Software and its engineering; Software and its engineering → Domain specific languages; Software and its engineering → API languages; Theory of computation → Cryptographic protocols

show abstract

You broke my code: understanding the motivations for breaking changes in APIs

Cited by 29 publications

References 48 publications

Deprewriter: On the fly rewriting method deprecations.

Deprewriter: On the fly rewriting method deprecations.

Challenges and Governance Solutions for Data Science Services based on Open Data and APIs

Dealing with Variability in API Misuse Specification

Contact Info

Product

Resources

About