API Usage Research Articles

Incorporating Code Structure and Quality in Deep Code Search

Developers usually search for reusable code snippets to improve software development efficiency. Existing code search methods, including methods based on full-text or deep learning, have two disadvantages: (1) ignoring structural information of code snippets, such as conditional statements and loop statements, and (2) ignoring quality information of code snippets, such as naming clarity and logical correctness. These disadvantages limit the performance of existing code search methods. In this paper, we propose a novel code search method named Structure and Quality based Deep Code Search (SQ-DeepCS). SQ-DeepCS introduces a code representation method called program slice to represent structual information as well as API usage of code snippets. Meanwhile, SQ-DeepCS introduces a novel deep neural network named Method-Description-Joint Embedding Neural Network (MD-JEnn) to weight the quality of code snippets. To evaluate the proposed methods, we train MD-JEnn and evaluate SQ-DeepCS by searching for code snippets with respect to the top-rated questions from Stack Overflow. We use four evaluation indicators to measure the effectiveness of SQ-DeepCS: FRank, SuccessRate@k, PrecisionRate@k, and Mean Reciprocal Rank (MRR). The experimental results show that our approach can provide better results than existing techniques when searching for relevant code snippets.

Towards cost-effective API deprecation: A win–win strategy for API developers and API users

API deprecation, which enables API developers to assist API users in migration tasks, has been widely employed in API removal management. However, mismanaged API deprecation will cause unnecessary cost and bring negligible benefit to API users. Cost-effective investments in API deprecation become challenges for API developers. In this work, an iterative model for cost-effective investments in API deprecation is developed. The model provides a data-driven mechanism for API developers to iteratively make investments in API deprecation. A tool named AWARE (A Win–win Assistant for API REmoval management) is also developed for API developers to accurately assess the benefit from the perspective of API usage statistics. Based on the prioritized benefit, API developers can allocate appropriate resources on API deprecation. A case study is performed to evaluate the effectiveness of the iterative model with AWARE. The evaluation result shows that the cost paid by API developers can be reduced significantly while the benefit brought to API users can be increased. A win–win strategy for API deprecation can be achieved.

Design of decision support system service in the Space Science Center using microservices approach

Development of the Decision Support Systems (DSS) has been written up in the Space Science Center’s roadmap for the next few years. The main programs have to be achieved such as related to the DSS are Space Weather, HF Radio Communication, Space Debris Monitoring, and Navigation activities. Of course, accessing those DSS services separately may become a problem for users who need information as fast as possible. We proposed an information system as a portal to integrate all DSS services collecting the latest information from each main program. We applied the microservice approach for design of this Information System prototype, which will it grows up as the modern application model that is capable to handle multiple features, high scalability but still lightweight. Microservices approach is a method that breaks an application into a single-function module for optimizing its performance. In addition, usage of web service technology and REST-ful API also can support system interoperability functions. In this design we conducted several stages, use case Diagrams, design of microservices database, and prototyping frontend pages in the results. This study purposes to provide an initial system design with a detailed explanation of specification requirements so that the design of the Decision Support System Service in the Space Science Center environment can be developed as expected.

1+1$>$2: Programming Know-What and Know-How Knowledge Fusion, Semantic Enrichment and Coherent Application

Software programming requires both API reference (know-what) knowledge and programming task (know-how) knowledge. Lots of programming know-what and know-how knowledge is documented in text, for example, API reference documentation and programming tutorials. To improve knowledge accessibility and usage, several recent studies use Natural Language Processing (NLP) methods to construct API know-what knowledge graph (API-KG) and programming task know-how knowledge graph (Task-KG) from software documentation. Although being promising, current API-KG and Task-KG are independent of each other, and thus are void of inherent connections between the two types of knowledge. Our empirical study on Stack Overflow questions confirms that only 36% of the API usage problems can be answered by the know-how or the know-what knowledge alone, while the rest questions requires a fusion of both. Inspired by this observation, we make the first attempt to fuse API-KG and Task-KG by API entity linking. This fusion creates nine categories of API semantic relations and two types of task semantic relations which are not present in the stand-alone API-KG or Task-KG. According to the definitions of these new API and task semantic relations, our approach dives deeper than surface-level API linking of API-KG and Task-KG, and infer nine categories of API semantic relations from task descriptions and two types of task semantic relations with the assistance of API-KG, which enrich the declaration or syntactic relations in the current API-KG and Task-KG. Our fused and semantically-enriched API-Task KG supports coherent API/Task-centric knowledge search by text or code queries. We have implemented our approach on Java programming documentation and built a web tool to search and explore API and programming task knowledge. Our evaluation confirms the high-accuracy of our knowledge extraction, fusion and enrichment methods, and the effectiveness and usefulness of our API-Task KG for answering Stack Overflow questions.

API beauty is in the eye of the clients: 2.2 million Maven dependencies reveal the spectrum of client–API usages

Hyrum’s law states a common observation in the software industry: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody”. Meanwhile, recent research results seem to contradict this observation when they state that “for most APIs, there is a small number of features that are actually used”. In this work, we perform a large scale empirical study of client–API relationships in the Maven ecosystem, in order to investigate this seeming paradox between the observations in industry and the research literature.We study the 94 most popular libraries in Maven Central, as well as the 829,410 client artifacts that declare a dependency to these libraries and that are available in Maven Central, summing up to 2.2M dependencies. Our analysis indicates the existence of a wide spectrum of API usages, with enough clients, most API types end up being used at least once. Our second key observation is that, for all libraries, there is a small set of API types that are used by the vast majority of its clients. The practical consequences of this study are two-fold: (i) it is possible for API maintainers to find an essential part of their API on which they can focus their efforts; (ii) API developers should limit the public API elements to the set of features for which they are ready to have users.

Demystifying regular expression bugs

Regular expressions cause string-related bugs and open security vulnerabilities for DOS attacks. However, beyond ReDoS (Regular expression Denial of Service), little is known about the extent to which regular expression issues affect software development and how these issues are addressed in practice. We conduct an empirical study of 356 regex-related bugs from merged pull requests in Apache, Mozilla, Facebook, and Google GitHub repositories. We identify and classify the nature of the regular expression problems, the fixes, and the related changes in the test code. The most important findings in this paper are as follows: 1) incorrect regular expression semantics is the dominant root cause of regular expression bugs (165/356, 46.3%). The remaining root causes are incorrect API usage (9.3%) and other code issues that require regular expression changes in the fix (29.5%), 2) fixing regular expression bugs is nontrivial as it takes more time and more lines of code to fix them compared to the general pull requests, 3) most (51%) of the regex-related pull requests do not contain test code changes. Certain regex bug types (e.g., compile error, performance issues, regex representation) are less likely to include test code changes than others, and 4) the dominant type of test code changes in regex-related pull requests is test case addition (75%). The results of this study contribute to a broader understanding of the practical problems faced by developers when using, fixing, and testing regular expressions.

The LRA Workbench: an IDE for efficient REST API composition through linked metadata

The number of Web APIs for accessing information and services is continuously increasing, and yet, no tools exist to automate the time-consuming and error-prone process of invoking those APIs and composing their responses. The recent emergence of widely-adopted, standardized, Web-API description formats and the development of Linked Data technologies for data integration have motivated our work on the LRA (Linked REST APIs) methodology [1, 2]. LRA relies on RDF service specifications to automate the development process around the usage of Web APIs. This automation represents a great opportunity to systematize and improve the quality of service-oriented application development. However, LRA’s reliance on SPARQL as the user-interaction model may hinder its adoption, because it requires developers to learn the intricacies of the unconventional graph data model and its associated datasets. In this paper we have developed the LRA Workbench (LRA_{Wbench}), which takes advantage of the emergent schema of Web-API specifications, in order to simplify the formulation of LRA-compliant SPARQL queries. Our empirical evaluation of the LRA_{Wbench} usability demonstrates that our tool significantly improves the performance of developers formulating SPARQL queries for LRA. A subsequent study on the effectiveness of the LRA_{Wbench} demonstrated that developers using LRA tend to produce code with considerable better structural complexity, in less time, than developers manually composing APIs.

API recommendation for Mashup creation based on neural graph collaborative filtering

With the increase of open APIs appeared on the Web, reusing or combining these APIs to develop novel applications (e.g. Mashups) has attracted great interest from developers. However, to quickly find a suitable one among a huge number of APIs to meet a developer’s requirement is basically a non-trivial issue. Therefore, a high-quality API recommendation system is desirable. Although a number of collaborative filtering methods have been proposed for API recommendation, their recommendation accuracy is limited and needs to be further improved. Based on the neural graph collaborative filtering technique, this paper proposes an API recommendation method that exploits the high-order connectivity between APIs and API users. To evaluate the proposed method, extensive experiments are conducted on a real API dataset and the results show that the proposed method outperforms the state-of-the-art methods in API recommendation.

Guided pattern mining for API misuse detection by change-based code analysis

Lack of experience, inadequate documentation, and sub-optimal API design frequently cause developers to make mistakes when re-using third-party implementations. Such API misuses can result in unintended behavior, performance losses, or software crashes. Therefore, current research aims to automatically detect such misuses by comparing the way a developer used an API to previously inferred patterns of the correct API usage. While research has made significant progress, these techniques have not yet been adopted in practice. In part, this is due to the lack of a process capable of seamlessly integrating with software development processes. Particularly, existing approaches do not consider how to collect relevant source code samples from which to infer patterns. In fact, an inadequate collection can cause API usage pattern miners to infer irrelevant patterns which leads to false alarms instead of finding true API misuses. In this paper, we target this problem (a) by providing a method that increases the likelihood of finding relevant and true-positive patterns concerning a given set of code changes and agnostic to a concrete static, intra-procedural mining technique and (b) by introducing a concept for just-in-time API misuse detection which analyzes changes at the time of commit. Particularly, we introduce different, lightweight code search and filtering strategies and evaluate them on two real-world API misuse datasets to determine their usefulness in finding relevant intra-procedural API usage patterns. Our main results are (1) commit-based search with subsequent filtering effectively decreases the amount of code to be analyzed, (2) in particular method-level filtering is superior to file-level filtering, (3) project-internal and project-external code search find solutions for different types of misuses and thus are complementary, (4) incorporating prior knowledge of the misused API into the search has a negligible effect.

Is the Sample Good Enough? Comparing Data from Twitter's Streaming API with Twitter's Firehose

Twitter is a social media giant famous for the exchange of short, 140-character messages called "tweets". In the scientific community, the microblogging site is known for openness in sharing its data. It provides a glance into its millions of users and billions of tweets through a "Streaming API" which provides a sample of all tweets matching some parameters preset by the API user. The API service has been used by many researchers, companies, and governmental institutions that want to extract knowledge in accordance with a diverse array of questions pertaining to social media. The essential drawback of the Twitter API is the lack of documentation concerning what and how much data users get. This leads researchers to question whether the sampled data is a valid representation of the overall activity on Twitter. In this work we embark on answering this question by comparing data collected using Twitter's sampled API service with data collected using the full, albeit costly, Firehose stream that includes every single published tweet. We compare both datasets using common statistical metrics as well as metrics that allow us to compare topics, networks, and locations of tweets. The results of our work will help researchers and practitioners understand the implications of using the Streaming API.

A Measurement Study of Wechat Mini-Apps

A new mobile computing paradigm, dubbed mini-app, has been growing rapidly over the past few years since being introduced by WeChat in 2017. In this paradigm, a host app allows its end-users to install and run mini-apps inside itself, enabling the host app to build an ecosystem around (much like Google Play and Apple AppStore), enrich the host's functionalities, and offer mobile users elevated convenience without leaving the host app. It has been reported that there are over millions of mini-apps in WeChat. However, little information is known about these mini-apps at an aggregated level. In this paper, we present MiniCrawler, the first scalable and open-source WeChat mini-app crawler that has indexed over 1,333,308 mini-apps. It leverages a number of reverse engineering techniques to uncover the interfaces and APIs in WeChat for crawling the mini-apps. With the crawled mini-apps, we then measure the resource consumption, API usage, library usage, obfuscation rate, app categorization, and app ratings at an aggregated level in this work.

A Measurement Study of Wechat Mini-Apps

A new mobile computing paradigm, dubbed mini-app, has been growing rapidly over the past few years since being introduced by WeChat in 2017. In this paradigm, a host app allows its end-users to install and run mini-apps inside itself, enabling the host app to build an ecosystem around (much like Google Play and Apple AppStore), enrich the host's functionalities, and offer mobile users elevated convenience without leaving the host app. It has been reported that there are over millions of mini-apps in WeChat. However, little information is known about these mini-apps at an aggregated level. In this paper, we present MiniCrawler, the first scalable and open source WeChat mini-app crawler that has indexed over 1,333,308 mini-apps. It leverages a number of reverse engineering techniques to uncover the interfaces and APIs in WeChat for crawling the mini-apps. With the crawled mini-apps, we then measure their resource consumption, API usage, library usage, obfuscation rate, app categorization, and app ratings at an aggregated level. The details of how we develop MiniCrawler and our measurement results are reported in this paper.

MainzelHandler: A Library for a Simple Integration and Usage of the Mainzelliste.

Pseudonymization plays a vital role in medical research. In Germany, the Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. (TMF) has developed guidelines on how to create pseudonyms and how to handle personally identifiable information (PII) during this process. An open-source implementation of a pseudonymization service following these guidelines and therefore recommended by the TMF is the so-called "Mainzelliste". This web application supports a REST-API for (de-) pseudonymization. For security reasons, a complex session and tokening mechanism for each (de-) pseudonymization is required and a careful interaction between front- and backend to ensure a correct handling of PII. The objective of this work is the development of a library to simplify the integration and usage of the Mainzelliste's API in a TMF conform way. The frontend library uses JavaScript while the backend component is based on Java with an optional Spring Boot extension. The library is available under MIT open-source license from https://github.com/DanielPreciado-Marquez/MainzelHandler.

Automatic API Usage Scenario Documentation from Technical Q&A Sites

The online technical Q&A site Stack Overflow (SO) is popular among developers to support their coding and diverse development needs. To address shortcomings in API official documentation resources, several research works have thus focused on augmenting official API documentation with insights (e.g., code examples) from SO. The techniques propose to add code examples/insights about APIs into its official documentation. Recently, surveys of software developers find that developers in SO consider the combination of code examples and reviews about APIs as a form of API documentation, and that they consider such a combination to be more useful than official API documentation when the official resources can be incomplete, ambiguous, incorrect, and outdated. Reviews are opinionated sentences with positive/negative sentiments. However, we are aware of no previous research that attempts to automatically produce API documentation from SO by considering both API code examples and reviews. In this article, we present two novel algorithms that can be used to automatically produce API documentation from SO by combining code examples and reviews towards those examples. The first algorithm is called statistical documentation, which shows the distribution of positivity and negativity around the code examples of an API using different metrics (e.g., star ratings). The second algorithm is called concept-based documentation, which clusters similar and conceptually relevant usage scenarios. An API usage scenario contains a code example, a textual description of the underlying task addressed by the code example, and the reviews (i.e., opinions with positive and negative sentiments) from other developers towards the code example. We deployed the algorithms in Opiner, a web-based platform to aggregate information about APIs from online forums. We evaluated the algorithms by mining all Java JSON-based posts in SO and by conducting three user studies based on produced documentation from the posts. The first study is a survey, where we asked the participants to compare our proposed algorithms against a Javadoc-syle documentation format (called as Type-based documentation in Opiner). The participants were asked to compare along four development scenarios (e.g., selection, documentation). The participants preferred our proposed two algorithms over type-based documentation. In our second user study, we asked the participants to complete four coding tasks using Opiner and the API official and informal documentation resources. The participants were more effective and accurate while using Opiner. In a subsequent survey, more than 80% of participants asked the Opiner documentation platform to be integrated into the formal API documentation to complement and improve the API official documentation.

Embedding API dependency graph for neural code generation

The problem of code generation from textual program descriptions has long been viewed as a grand challenge in software engineering. In recent years, many deep learning based approaches have been proposed, which can generate a sequence of code from a sequence of textual program description. However, the existing approaches ignore the global relationships among API methods, which are important for understanding the usage of APIs. In this paper, we propose to model the dependencies among API methods as an API dependency graph (ADG) and incorporate the graph embedding into a sequence-to-sequence (Seq2Seq) model. In addition to the existing encoder-decoder structure, a new module named ``embedder" is introduced. In this way, the decoder can utilize both global structural dependencies and textual program description to predict the target code. We conduct extensive code generation experiments on three public datasets and in two programming languages (Python and Java). Our proposed approach, called ADG-Seq2Seq, yields significant improvements over existing state-of-the-art methods and maintains its performance as the length of the target code increases. Extensive ablation tests show that the proposed ADG embedding is effective and outperforms the baselines.

GDroid: Android malware detection and classification with graph convolutional network

The dramatic increase in the number of malware poses a serious challenge to the Android platform and makes it difficult for malware analysis. In this paper, we propose a novel approach for Android malware detection and familial classification based on the Graph Convolutional Network (GCN). The general idea is to map apps and Android APIs into a large heterogeneous graph, converting the original problem into a node classification task. We build the “App-API” and “API-API” edges based on the invocation relationship and the API usage patterns, respectively. The heterogeneous graph is then fed into the GCN model, iteratively generating node embeddings that incorporate topological structure and node features. Eventually, the unlabeled apps are classified by their final embeddings. To our knowledge, this paper is the first study to explore the application of graph neural network in the field of malware classification. We develop a prototype system named GDroid. Experiments show that GDroid can effectively detect 98.99% of Android malware with a low false positive rate of less than 1%, outperforming the existing approaches. It also achieves an average accuracy of almost 97% in the malware familial classification task with surpassing the baselines. Additionally, we cooperate with QI-ANXIN Technology Research Institute to evaluate its real-world impact, and GDroid also maintains satisfactory performance in real-world scenarios.

Mining Likely Analogical APIs Across Third-Party Libraries via Large-Scale Unsupervised API Semantics Embedding

Establishing API mappings between third-party libraries is a prerequisite step for library migration tasks. Manually establishing API mappings is tedious due to the large number of APIs to be examined. Having an automatic technique to create a database of likely API mappings can significantly ease the task. Unfortunately, existing techniques either adopt supervised learning mechanism that requires already-ported or functionality similar applications across major programming languages or platforms, which are difficult to come by for an arbitrary pair of third-party libraries, or cannot deal with lexical gap in the API descriptions of different libraries. To overcome these limitations, we present an unsupervised deep learning based approach to embed both API usage semantics and API description (name and document) semantics into vector space for inferring likely analogical API mappings between libraries. Based on deep learning models trained using tens of millions of API call sequences, method names and comments of 2.8 millions of methods from 135,127 GitHub projects, our approach significantly outperforms other deep learning or traditional information retrieval (IR) methods for inferring likely analogical APIs. We implement a proof-of-concept website ( https://similarapi.appspot.com ) which can recommend analogical APIs for 583,501 APIs of 111 pairs of analogical Java libraries with diverse functionalities. This scale of third-party analogical-API database has never been achieved before.

A Wizard of Oz Study Simulating API Usage Dialogues With a Virtual Assistant

Virtual Assistant technology is rapidly proliferating to improve productivity in a variety of tasks. While several virtual assistants for everyday tasks are well-known (e.g., Siri, Cortana, Alexa), assistants for specialty tasks such as software engineering are rarer. One key reason software engineering assistants are rare is that very few experimental datasets are available and suitable for training the AI that is the bedrock of current virtual assistants. In this paper, we present a set of Wizard of Oz experiments that we designed to build a dataset for creating a virtual assistant. Our target is a hypothetical virtual assistant for helping programmers use APIs. In our experiments, we recruited 30 professional programmers to complete programming tasks using two APIs. The programmers interacted with a simulated virtual assistant for help - the programmers were not aware that the assistant was actually operated by human experts. We then annotated the dialogue acts in the corpus along four dimensions: illocutionary intent, API information type(s), backward-facing function, and traceability to specific API components. We observed a diverse range of interactions that will facilitate the development of dialogue strategies for virtual assistants for API usage.

Actor concurrency bugs: a comprehensive study on symptoms, root causes, API usages, and differences

Actor concurrency is becoming increasingly important in the development of real-world software systems. Although actor concurrency may be less susceptible to some multithreaded concurrency bugs, such as low-level data races and deadlocks, it comes with its own bugs that may be different. However, the fundamental characteristics of actor concurrency bugs, including their symptoms, root causes, API usages, examples, and differences when they come from different sources are still largely unknown. Actor software development can significantly benefit from a comprehensive qualitative and quantitative understanding of these characteristics, which is the focus of this work, to foster better API documentation, development practices, testing, debugging, repairing, and verification frameworks. To conduct this study, we take the following major steps. First, we construct a set of 186 real-world Akka actor bugs from Stack Overflow and GitHub via manual analysis of 3,924 Stack Overflow questions, answers, and comments and 3,315 GitHub commits, messages, original and modified code snippets, issues, and pull requests. Second, we manually study these actor bugs and their fixes to understand and classify their symptoms, root causes, and API usages. Third, we study the differences between the commonalities and distributions of symptoms, root causes, and API usages of our Stack Overflow and GitHub actor bugs. Fourth, we discuss real-world examples of our actor bugs with these symptoms and root causes. Finally, we investigate the relation of our findings with those of previous work and discuss their implications. A few findings of our study are: (1) symptoms of our actor bugs can be classified into five categories, with Error as the most common symptom and Incorrect Exceptions as the least common, (2) root causes of our actor bugs can be classified into ten categories, with Logic as the most common root cause and Untyped Communication as the least common, (3) a small number of Akka API packages are responsible for most of API usages by our actor bugs, and (4) our Stack Overflow and GitHub actor bugs can differ significantly in commonalities and distributions of their symptoms, root causes, and API usages. While some of our findings agree with those of previous work, others sharply contrast.

API recommendation for the development of Android App features based on the knowledge mined from App stores

To improve the efficiency, developers tend to use APIs to avoid reinventing wheels in the development of Apps. However, there are thousands of APIs for various purposes, so it is difficult for developers to identify suitable APIs according to the functionalities to be realized. App stores manage millions of products, which embody the experience and wisdom of developers, and they provide valuable data resource for solving this problem. By summarizing the API usage for the same or similar functionalities in Apps, reusable knowledge can be mined for the API recommendation. In this paper, we utilize the data resource in App stores and provide an API recommendation method for the development of Android Apps. Firstly, by using UI elements as the bridge, we establish mapping relationships between functionalities and APIs. Secondly, we build a framework to describe functionalities of Apps in the same category, and utilize relationships between functionalities and APIs to construct the API knowledge for each node in the framework. Thirdly, we identify nodes according to queried features and show the API knowledge to developers by giving recommendation lists. We conducted experiments based on Google Play, and the result shows that our method has a good recommendation performance. • We bring the data resource of App stores to the API recommending for developers. • Using UI as the bridge to establish the relationships between App features and APIs. • Establish a framework to recommend APIs for features with different granularities.