An Application Programming Interface (API) provides a set of functionalities to a developer with the aim of enabling reuse. APIs have been investigated from different angles such as popularity usage and evolution to get a better understanding of their various characteristics. For such studies, software repositories are mined for API usage examples. However, many of the mining algorithms used for such purposes do not take type information into account. Thus making the results unreliable. In this paper, we aim to rectify this by introducing fine-GRAPE, an approach that produces fine-grained API usage information by taking advantage of type information while mining API method invocations and annotation. By means of fine-GRAPE, we investigate API usages from Java projects hosted on GitHub. We select five of the most popular APIs across GitHub Java projects and collect historical API usage information by mining both the release history of these APIs and the code history of every project that uses them. We perform two case studies on the resulting dataset. The first measures the lag time of each client. The second investigates the percentage of used API features. In the first case we find that for APIs that release more frequently clients are far less likely to upgrade to a more recent version of the API as opposed to clients of APIs that release infrequently. The second case study shows us that for most APIs there is a small number of features that is actually used and most of these features relate to those that have been introduced early in the APIs lifecycle.@en

Application Programming Interfaces (API) provide reusable functionality to aid developers in the development process. The features provided by these APIs might change over time as the API evolves. To allow API consumers to peacefully transition from older obsolete features to new features, API producers make use of the deprecation mechanism that allows them to indicate to the consumer that a feature should no longer be used. The Java language designers noticed that no one was taking these deprecation warnings seriously and continued using outdated features. Due to this, they decided to change the implementation of this feature in Java 9. We question as to what extent this issue exists and whether the Java language designers have a case. We start by identifying the various ways in which an API consumer can react to deprecation. Following this we benchmark the frequency of the reaction patterns by creating a dataset consisting of data mined from 50 API consumers totalling 297,254 GitHub based projects and 1,322,612,567 type-checked method invocations. We see that predominantly consumers do not react to deprecation and we try to explain this behavior by surveying API consumers and by analyzing if the API’s deprecation policy has an impact on the consumers’ decision to react.@en

Peer code review is a practice widely adopted in software projects to improve the quality of code. In current code review practices, code changes are manually inspected by developers other than the author before these changes are integrated into a project or put into production. We conducted a study to obtain an empirical understanding of what makes a code change easier to review. To this end, we surveyed published academic literature and sources from gray literature (e.g., blogs and white papers), we interviewed ten professional developers, and we designed and deployed a reviewability evaluation tool that professional developers used to rate the reviewability of 98 changes. We find that reviewability is defined through several factors, such as the change description, size, and coherent commit history. We provide recommendations for practitioners and researchers. Preprint [https://pure.tudelft.nl/portal/files/45941832/reviewability.pdf]. Data and Materials [https://doi.org/10.5281/zenodo.1323659].@en

Peer code review is a practice widely adopted in software projects to improve the quality of code. In current code review practices, code changes are manually inspected by developers other than the author before these changes are integrated into a project or put into production. We conducted a study to obtain an empirical understanding of what makes a code change easier to review. To this end, we surveyed published academic literature and sources from gray literature (e.g., blogs and white papers), we interviewed ten professional developers, and we designed and deployed a reviewability evaluation tool that professional developers used to rate the reviewability of 98 changes. We find that reviewability is defined through several factors, such as the change description, size, and coherent commit history. We provide recommendations for practitioners and researchers. Preprint [https://pure.tudelft.nl/portal/files/45941832/reviewability.pdf]. Data and Materials [https://doi.org/10.5281/zenodo.1323659].@en

In this study, we investigate why API producers deprecate features. Previous work has shown us that knowing the rationale behind deprecation of an API aids a consumer in deciding to react, thus hinting at a diversity of deprecation reasons. We manually analyze the Javadoc of 374 deprecated methods pertaining four mainstream Java APIs to see whether the reason behind deprecation is mentioned. We find that understanding the rationale from just the Javadoc is insufficient; hence we add other data sources such as the source code, issue tracker data and commit history. We observe 12 reasons that trigger API producers to deprecate a feature. We evaluate an automated approach to classify these motivations.@en

Application Programming Interfaces (APIs) are a tremendous resource—that is, when they are stable. Several studies have shown that this is unfortunately not the case. Of those, a large-scale study of API changes in the Pharo Smalltalk ecosystem documented several findings about API deprecations and their impact on API clients. We extend this study, by analyzing clients of both popular third-party Java APIs and the JDK API. This results in a dataset consisting of more than 25,000 clients of five popular Java APIs on GitHub, and 60 clients of the JDK API from Maven Central. This work addresses several shortcomings of the previous study, namely: a study of several distinct API clients in a popular, statically-typed language, with more accurate version information. We compare and contrast our findings with the previous study and highlight new ones, particularly on the API client update practices and the startling similarities between reaction behavior in Smalltalk and Java. We make a comparison between reaction behavior for third-party APIs and JDK APIs, given that language APIs are a peculiar case in terms of wide-spread usage, documentation, and support from IDEs. Furthermore, we investigate the connection between reaction patterns of a client and the deprecation policy adopted by the API used.@en

Application Programming Interfaces (APIs) are a tremendous resource—that is, when they are stable. Several studies have shown that this is unfortunately not the case. Of those, a large-scale study of API changes in the Pharo Smalltalk ecosystem documented several findings about API deprecations and their impact on API clients. We conduct a partial replication of this study, considering more than 25,000 clients of five popular Java APIs on GitHub. This work addresses several shortcomings of the previous study, namely: a study of several distinct API clients in a popular, statically-typed language, with more accurate version information. We compare and contrast our findings with the previous study and highlight new ones, particularly on the API client update practices and the startling similarities between reaction behavior in Smalltalk and Java.@en

Deprecation is a language feature that allows API producers to mark a feature as obsolete. We aim to gain a deep understanding of the needs of API producers and consumers alike regarding deprecation. To that end, we investigate why API producers deprecate features, whether they remove deprecated features, how they expect consumers to react, and what prompts an API consumer to react to deprecation. To achieve this goal we conduct semi-structured interviews with 17 third-party Java API producers and survey 170 Java developers. We observe that the current deprecation mechanism in Java and the proposal to enhance it does not address all the needs of a developer. This leads us to propose and evaluate three further enhancements to the deprecation mechanism. @en

The practice of software engineering involves the combination of existing software components with new functionality to create new software. This is where an Application Programming Interface (API) comes in, an API is a definition of a set of functionality that can be reused by a developer to incorporate certain functionality in their codebase. Using an API can be challenging. For example, adopting a new API and correctly using the functionality can be challenging. One of the biggest issues with using an API, is that the API can evolve, with new features being added or existing features being modified or removed. Dealing with this challenge has led to an entire line of research on API evolution. In this thesis, we seek to understand to what extent API evolution more specifically API deprecation affects API consumers and how API consumers deal with the changing API. API producers can impact consumer behavior by adopting specific deprecation policies, to uncover the nature of this relationship, we investigate how and why the API producer deprecates the API and how this impacts the consumer. Deprecation is a language feature, i.e. one that language designers implement. Its implementation can vary across languages and thus the information that is conveyed by the deprecation mechanism can vary as well. The specific design decisions taken by the language designers can have a direct impact on consumer behavior when it comes to dealing with deprecation. We investigate the language designer perspective on deprecation and the impact of the design of a deprecation mechanism on the consumer. In this thesis, we investigate the relationship between API consumers, API producers, and language designers to understand how each has a role to play in reducing the burden of dealing with API evolution. Our findings show that out of the projects that are affected by deprecation of API elements, only a minority react to the deprecation of an API element. Furthermore, out of this minority, an even smaller proportion reacts by replacing the deprecated element with the recommended replacement. A larger proportion of the projects prefer to rollback the version of the API that they use so that they are not affected by deprecation, another faction of projects is more willing to replace the API with the deprecated element with another API. API producers have a direct impact on this behavior with the deprecation policy of the API having a direct impact on the consumer's decision to react to deprecation. If the API producer is more likely to clean up their code i.e. remove the deprecated element, then the consumers are likely to react to the deprecation of the element. This shows us that even for non-web-based APIs, the API producers can impact consumer behavior. We also, observe that the nature and content of the deprecation message can have an impact on consumer behavior. Consumers prefer to know when a deprecated feature is going to go away, what its replacement is and the reason behind the deprecation (informing them of the immediacy of reacting to the deprecation). The design of the deprecation mechanism needs to reflect these needs as the deprecation mechanism is the only direct way in which API producers can communicate with the consumer.@en

One of the tasks of reviewers is to verify that code modifications are well tested. However, current tools offer little support in understanding precisely how changes to the code relate to changes to the tests. In particular, it is hard to see whether (modified) test code covers the changed code. To mitigate this problem, we developed OPERIAS, a tool that provides a combined visualization of fine-grained source code differences and coverage impact. OPERIAS works both as a stand-Alone tool on specific project versions and as a service hooked to GitHub. In the latter case, it provides automated reports for each new pull request, which reviewers can use to assess the code contribution. OPERIAS works for any Java project that works with maven and its standard Cobertura coverage plugin. We present how OPERIAS could be used to identify test-related problems in real-world pull requests. OPERIAS is open source and available on GitHub with a demo video: https://github.com/SERG-Delft/operias.@en

We propose an initial approach to minethe usage trends of libraries in Haskell, a popular functional programming language. We integrate it with a novel, initial method to automatically determine the reasons of clients for switching to different versions. Based onthese, we conduct a preliminary investigation of trends of usage in Haskelllibraries. Results suggest that trends are similar to those in the Javaecosystem and in line with Rogers' theory on the diffusion of innovation. Our results also provide indication on Haskell libraries being allby and large stable.@en

We propose an initial approach to minethe usage trends of libraries in Haskell, a popular functional programming language. We integrate it with a novel, initial method to automatically determine the reasons of clients for switching to different versions. Based onthese, we conduct a preliminary investigation of trends of usage in Haskelllibraries. Results suggest that trends are similar to those in the Javaecosystem and in line with Rogers' theory on the diffusion of innovation. Our results also provide indication on Haskell libraries being allby and large stable.@en