How do APIs evolve? A story of refactoring

Abstract

Frameworks and libraries change their APIs. Migrating an application to the new API is tedious and disrupts the development process. Although some tools and ideas have been proposed to solve the evolution of APIs, most updates are done manually. To better understand the requirements for migration tools, we studied the API changes of four frameworks and one library. We discovered that the changes that break existing applications are not random, but tend to fall into particular categories. Over 80% of these changes are refactorings. This suggests that refactoring-based migration tools should be used to update applications.way to update component-based applications. This paper is the beginning of our quest to meet the needs of both component and application developers. What is a suitable representation for the changes that happened in a component? Can it be gathered automatically? Does this representation carry both the syntax and the semantics of changes? Can it lead to safe, automatic updating of component-based applications? How much of the effort spent on updating component-based applications can be saved?Although there are principles of software evolution that are true for software in any language, programming languages have an impact on software evolution. We are particularly interested in the evolution of object-oriented components (we refer to both the library and framework as components, unless a distinction is necessary). Classes contain a mixture of private and public methods. The public methods are those that are meant to be used by application programmers. The set of public methods of a class library make up its application programmer interface (API). Changes to private methods and classes do not pose a problem to application developers; they only care about changes to the API.An important kind of change to object-oriented software is a refactoring [4]. Refactorings are program transformations that change the structure of a program but not its behavior. Refactorings include renaming classes or methods, moving methods or variables between classes, and splitting methods or classes. A refactoring that changes the interface of an object must change all of its clients to use the new interface. When a class library that is reused in many systems is refactored, the systems that reuse it must change. However, those developing the library often do not know all of the systems that reuse it. The new version of the library is a refactoring from their point of view, but not from the point of view of the application developers who are their customers.The original work on refactoring was motivated by framework evolution. Opdyke and Johnson [5] looked at the Choices operating system and the kind of refactorings that occurred as it evolved. Graver [6] studied an object-oriented compiler framework as it went through three iterations. Tokuda and Batory [7] describe the evolution of two frameworks, focusing on how large architectural changes can be accomplished by a sequence of refactorings.However, none of these studies d...

On the reaction to deprecation of clients of 4 + 1 popular Java APIs and the JDK

“…Dig and Johnson studied and classified the API breaking changes in 4 APIs (Dig and Johnson 2006); they did not investigate their impact on clients. They found that 80% of the changes were due to refactorings.…”

An empirical study on the impact of refactoring activities on evolving client-used APIs

“…All libraries constitute a large client-base and are from different application domains. Moreover, three out of the eight subject libraries were used in prior work [8,9,10]. The chosen studied libraries range from being testing, logging, utilities and web-based libraries.…”

“…Related, Dig and Johnson [9] manually inspected library release notes for documented API changes to investigate the role of refactoring during API evolution of a library. They cited two reasons why they preferred a manual analysis over the use of automated tools: (1) 'since most API changes follow a long deprecation replace-remove cycle, an obsolete API can coexist with the new API for a long time' and (2) some behavioral refactoring cases that 'would have been misinterpreted by a tool, but a human expert can easily spot'.…”

“…In the first example (i.e., Figure 9a, we show an unavoidable API breaking change, especially if it is used to fix a complex defect such as a third party library. This API breaking change was triggered in response to an error reported by a client user "JDK and Guava TypeVariable implementations are no longer compatible under 1.7.0 51-b13" 9 It was widely reported to affect many client users of the library. Developers found that a change in the standard Java library (JDK) causes guava to break API compatibility, as prior guava version implemented an undocumented internal API of the JDK (i.e., Types.TypeVariable.newTypeVariable()) 10 .…”

“…As outlined in Section 4.1 there are obvious differences with our approach, compared to the studies of Dig and Johnson [9] and Cossette et al [8]. Dig public entities are APIs.…”