How Java APIs break – An empirical study

ContextIt has become common practice to build programs by using libraries. While the benefits of reuse are well known, an often overlooked risk are system runtime failures due to API changes in libraries that evolve independently. Traditionally, the consistency between a program and the libraries it uses is checked at build time when the entire system is compiled and tested. However, the trend towards partially upgrading systems by redeploying only evolved library versions results in situations where these crucial verification steps are skipped. For Java programs, partial upgrades create additional interesting problems as the compiler and the virtual machine use different rule sets to enforce contracts between the providers and the consumers of APIs.ObjectiveWe have studied the extent of the problem in real world programs. We were interested in two aspects: the compatibility of API changes as libraries evolve, and the impact this has on programs using these libraries.MethodThis study is based on the qualitas corpus version 20120401. A data set consisting of 109 Java open-source programs and 564 program versions was used from this corpus. We have investigated two types of library dependencies: explicit dependencies to embedded libraries, and dependencies defined by symbolic references in Maven build files that are resolved at build time. We have used JaCC for API analysis, this tool is based on the popular ASM byte code analysis library.ResultsWe found that for most of the programs we investigated, APIs are unstable as incompatible changes are common. Surprisingly, there are more compatibility problems in projects that use automated dependency resolution. However, we found only a few cases where this has an actual impact on other programs using such an API.ConclusionIt is concluded that API instability is common and causes problems for programs using these APIs. Therefore, better tools and methods are needed to safeguard library evolution.     

Adoption and use of Java generics

Support for generic programming was added to the Java language in 2004, representing perhaps the most significant change to one of the most widely used programming languages today. Researchers and language designers anticipated this addition would relieve many long-standing problems plaguing developers, but surprisingly, no one has yet measured how generics have been adopted and used in practice. In this paper, we report on the first empirical investigation into how Java generics have been integrated into open source software by automatically mining the history of 40 popular open source Java programs, traversing more than 650 million lines of code in the process. We evaluate five hypotheses and research questions about how Java developers use generics. For example, our results suggest that generics sometimes reduce the number of type casts and that generics are usually adopted by a single champion in a project, rather than all committers. We also offer insights into why some features may be adopted sooner and others features may be held back.     

Java Insecurity: Accounting for Subtleties That Can Compromise Code

Conscientious Java developers are typically aware of the numerous coding guidelines that they should follow when writing code, such as validating inputs, minimizing accessibility to classes and members, and avoiding public static nonfinal fields. Java developers follow such guidelines to avoid common programming pitfalls (often called antipatterns), thereby reducing the likelihood of bugs or security vulnerabilities in their programs.     

Software Bertillonage

Deployed software systems are typically composed of many pieces, not all of which may have been created by the main development team. Often, the provenance of included components—such as external libraries or cloned source code—is not clearly stated, and this uncertainty can introduce technical and ethical concerns that make it difficult for system owners and other stakeholders to manage their software assets. In this work, we motivate the need for the recovery of the provenance of software entities by a broad set of techniques that could include signature matching, source code fact extraction, software clone detection, call flow graph matching, string matching, historical analyses, and other techniques. We liken our provenance goals to that of Bertillonage, a simple and approximate forensic analysis technique based on bio-metrics that was developed in 19th century France before the advent of fingerprints. As an example, we have developed a fast, simple, and approximate technique called anchored signature matching for identifying the source origin of binary libraries within a given Java application. This technique involves a type of structured signature matching performed against a database of candidates drawn from the Maven2 repository, a 275 GB collection of open source Java libraries. To show the approach is both valid and effective, we conducted an empirical study on 945 jars from the Debian GNU/Linux distribution, as well as an industrial case study on 81 jars from an e-commerce application.     

Exception handling bug hazards in Android

Adequate handling of exceptions has proven difficult for many software engineers. Mobile app developers in particular, have to cope with compatibility, middleware, memory constraints, and battery restrictions. The goal of this paper is to obtain a thorough understanding of common exception handling bug hazards that app developers face. To that end, we first provide a detailed empirical study of over 6,000 Java exception stack traces we extracted from over 600 open source Android projects. Key insights from this study include common causes for system crashes, and common chains of wrappings between checked and unchecked exceptions. Furthermore, we provide a survey with 71 developers involved in at least one of the projects analyzed. The results corroborate the stack trace findings, and indicate that developers are unaware of frequently occurring undocumented exception handling behavior. Overall, the findings of our study call for tool support to help developers understand their own and third party exception handling and wrapping logic.     

Backward compatibility of software interfaces: Steps towards automatic verification

This paper discusses problems of ensuring backward compatibility between new and old versions of software components (e.g., libraries). The Linux environment is considered as the main example. Breach of the compatibility in a new version of a software component may result in crashing or incorrect behavior (at the binary level) or inability to build (at the source level) applications targeted at a previous version of the component when the applications are used with the new version of the component. The paper describes typical issues that cause backward compatibility problems at the binary level and presents a new method for automatic detection of such issues in the course of the component development, with the main attention being focused on changes in structure of interfaces. The C and C++ languages are used to exemplify the approach, although it can be applied to other languages, such as Java or C#, as well. Unlike the existing means, the suggested method can verify a broad spectrum of backward compatibility problems by comparing function signatures and type definitions obtained from the component??s header files in addition to analyzing symbols in the component??s binaries. This paper also describes an automated checker tool that implements the suggested method together with some results of its practical usage. In conclusion, further improvements of automatic means for backward compatibility verification are discussed.     

CHECKERDROID : Automated Quality Assurance for Smartphone Applications

Smartphone applications'' quality is vital. However, many smartphone applications on market suffer from various bugs. One major reason is that developers lack viable techniques to help expose potential bugs in their applications. This paper presents a practical dynamic analysis tool, CheckerDroid, to help developers automatically detect both functional and non-functional bugs in their Android applications. CheckerDroid currently supports the detection of the following three types of bugs: null pointer exception, resource leak and sensor listener misusage. We built CheckerDroid by extending Java PathFinder (JPF), a widely-used model checker for general Java programs. Our extension addresses two technical challenges. First, Android applications are event-driven and lack explicit control flow information between event handlers. Second, Android applications closely hinge on native framework libraries, whose implementations are platform-dependent. To address these challenges, we derive event handler scheduling policies from Android documentations, and encode them to guide CheckerDroid to realistically execute Android applications. Besides, we modeled the side effects for a critical set of Android APIs such that CheckerDroid can conduct bug detection precisely. To evaluate CheckerDroid, we conducted experiments with seven popular real-world Android applications. CheckerDroid analyzed these applications in a few minutes, and successfully located real bugs in them.     

Where to publish and find ontologies? A survey of ontology libraries

One of the key promises of the Semantic Web is its potential to enable and facilitate data interoperability. The ability of data providers and application developers to share and reuse ontologies is a critical component of this data interoperability: if different applications and data sources use the same set of well defined terms for describing their domain and data, it will be much easier for them to “talk” to one another. Ontology libraries are the systems that collect ontologies from different sources and facilitate the tasks of finding, exploring, and using these ontologies. Thus ontology libraries can serve as a link in enabling diverse users and applications to discover, evaluate, use, and publish ontologies. In this paper, we provide a survey of the growing—and surprisingly diverse—landscape of ontology libraries. We highlight how the varying scope and intended use of the libraries affects their features, content, and potential exploitation in applications. From reviewing 11 ontology libraries, we identify a core set of questions that ontology practitioners and users should consider in choosing an ontology library for finding ontologies or publishing their own. We also discuss the research challenges that emerge from this survey, for the developers of ontology libraries to address.     

RUGRAT: Evaluating program analysis and testing tools and compilers with large generated random benchmark applications

Benchmarks are heavily used in different areas of computer science to evaluate algorithms and tools. In program analysis and testing, open‐source and commercial programs are routinely used as benchmarks to evaluate different aspects of algorithms and tools. Unfortunately, many of these programs are written by programmers who introduce different biases, not to mention that it is very difficult to find programs that can serve as benchmarks with high reproducibility of results. We propose a novel approach for generating random benchmarks for evaluating program analysis and testing tools and compilers. Our approach uses stochastic parse trees, where language grammar production rules are assigned probabilities that specify the frequencies with which instantiations of these rules will appear in the generated programs. We implemented our tool for Java and applied it to generate a set of large benchmark programs of up to 5M lines of code each with which we evaluated different program analysis and testing tools and compilers. The generated benchmarks let us independently rediscover several issues in the evaluated tools. Copyright © 2014 John Wiley & Sons, Ltd.     

C-Java自动程序转换系统的设计

程序设计语言的相互转换技术可以被广泛运用在软件维护、遗留系统的升级改造以及软件逆向工程等领域中。文中先对现有的几种移植方法进行了分析和研究,分析表明在将程序库移植到Java中和将它们与Java整合时,这些方法暴露出了各自的局限性和不足。借鉴语言转换经验,制定了转换的设计原则并探讨了将C语言转换到Java语言的过程中需要解决的一些问题,以及这个转换系统的设计思想和实现方法。文中所阐述的内容为实现异种程序设计语言的程序代码转换,提高程序代码的可移植性和重用性提供了有意义的思路和实现方法。     

Source Transformation for Concurrency Analysis

Concurrent programming poses a unique set of problems for quality assurance. These difficulties include the complexities of deadlock, livelock and divergence, which can be extremely difficult to detect and debug. A variety of tools have been developed to assist designers and developers of concurrent applications. Some of these tools, such as VeriSoft, are specific to particular implementation languages, such as C++.The Java Remote Method Invocation (Java RMI) package facilitates the implementation of concurrent applications, including those where processes reside on different hosts and communicate over networks. Unfortunately, it does not relieve the developer from the potential pitfalls of controlling concurrent access to remote objects, and may, in fact, make concurrency problems even more difficult to find.This paper presents an approach that allows the VeriSoft state exploration system to be used to analyze Java RMI programs for deadlock, livelock, divergence, and assertion violations. The system works by transforming Java RMI programs into C++ programs where Java syntax, structure, concurrency and memory management are replaced by C++ equivalents and Java RMI communication has been transformed to VeriSoft C++ inter-process communication. We present the details of this transformation and discuss preliminary results for a number of small examples.     

Improving the Quality of Web-based Enterprise Applications with Extended Static Checking: A Case Study

ESC/Java2 is a tool that statically detects errors in Java programs and that uses the Java Modeling Language (JML) as its annotation language. ESC/Java2 can modularly reason about the code of a Java Web-based Enterprise Application (WEA) and uncover potential errors. In this paper, we assessed the effectiveness of ESC/Java2 at helping developers increase WEA quality by detecting design and implementation issues.     

Toward Automated Support for Transparent Interoperable Queries

Many Object-Oriented Databases (OODBs) use programming languages that predate Java, such as C++, CLOS and Smalltalk. Thus, there is a growing need for interoperating these OODBs with new applications that require Java. Unfortunately, there are few mechanisms that allow software developers to easily integrate Java applications with non-Java OODBs. Although various interoperability mechanisms have been developed over the years, these approaches have some significant drawbacks in practice. They are often difficult to use, provide little, if any, automated support, and produce software that is difficult to engineer and maintain. In this paper, we describe an interoperability approach that allows application developers to seamlessly and transparently access non-Java OODBs from Java applications. We first present JOQL, a Java-based object query language that we are developing. JOQL queries are embedded in Java applications and are used to perform queries over C++-based OODBs. We also describe an accompanying toolset that processes Java programs containing JOQL queries. The toolset produces all the necessary code allowing Java applications to access and manipulate a C++-based OODB. As a result, application developers are free to work in Java without having to concern themselves with the details of interoperating with C++. Finally, we provide some preliminary experimental data that demonstrates our approach incurs a reasonable performance overhead.     

What do developers search for on the web?

Developers commonly make use of a web search engine such as Google to locate online resources to improve their productivity. A better understanding of what developers search for could help us understand their behaviors and the problems that they meet during the software development process. Unfortunately, we have a limited understanding of what developers frequently search for and of the search tasks that they often find challenging. To address this gap, we collected search queries from 60 developers, surveyed 235 software engineers from more than 21 countries across five continents. In particular, we asked our survey participants to rate the frequency and difficulty of 34 search tasks which are grouped along the following seven dimensions: general search, debugging and bug fixing, programming, third party code reuse, tools, database, and testing. We find that searching for explanations for unknown terminologies, explanations for exceptions/error messages (e.g., HTTP 404), reusable code snippets, solutions to common programming bugs, and suitable third-party libraries/services are the most frequent search tasks that developers perform, while searching for solutions to performance bugs, solutions to multi-threading bugs, public datasets to test newly developed algorithms or systems, reusable code snippets, best industrial practices, database optimization solutions, solutions to security bugs, and solutions to software configuration bugs are the most difficult search tasks that developers consider. Our study sheds light as to why practitioners often perform some of these tasks and why they find some of them to be challenging. We also discuss the implications of our findings to future research in several research areas, e.g., code search engines, domain-specific search engines, and automated generation and refinement of search queries.     

Javigator:Java代码导读及分析管理工具的设计

为克服阅读理解源代码的困难,根据现有的软件开发辅助工具的特点,对源代码导读和管理工具进行了深入的分析和研究.针对业界大量使用的Java语言,设计并实现了一个旨在以Java源代码导读为主、并具代码抽取等分析管理功能的交互式软件开发辅助工具Javigator.作为Eclipse的插件,能帮助开发人员快速地阅读理解Java源程序,并支撑对关注代码的快速测试及代码重用.Javigator使用灵活方便,可明显降低开发中理解及管理源代码的难度,提高开发的效率.     

Experience report: investigating bug fixes in machine learning frameworks/libraries

Machine learning (ML) techniques and algorithms have been successfully and widely used in various areas including software engineering tasks. Like other software projects, bugs are also common in ML projects and libraries. In order to more deeply understand the features related to bug fixing in ML projects, we conduct an empirical study with 939 bugs from five ML projects by manually examining the bug categories, fixing patterns, fixing scale, fixing duration, and types of maintenance. The results show that (1) there are commonly seven types of bugs in ML programs; (2) twelve fixing patterns are typically used to fix the bugs in ML programs; (3) 68.80% of the patches belong to micro-scale-fix and small-scale-fix; (4) 66.77% of the bugs in ML programs can be fixed within one month; (5) 45.90% of the bug fixes belong to corrective activity from the perspective of software maintenance. Moreover, we perform a questionnaire survey and send them to developers or users of ML projects to validate the results in our empirical study. The results of our empirical study are basically consistent with the feedback from developers. The findings from the empirical study provide useful guidance and insights for developers and users to effectively detect and fix bugs in MLprojects.     

Software quality practices — an empirical study

Concern about the quality of software is widespread. Reliable data about current practice are hard to get as no one likes to admit that they are producing poor software. In a recent survey, Wilson has taken an approach to obtaining data about the practice of software quality assurance among companies in Australia. The same technique has been used here to investigate practice among companies in Europe and America. The survey ams to investigate quality systems used by the organizations, and the application of these systems by software fevelopers. In this paper they are compared with the Australian experience and the results of the survey shown. The company's demographic data and overall response pattern from this survey are compared with Wilson's. Patterns in software quality assurance programs of organizations are suggested by comparing the management's perspective with that of the developers. The most popular software development techniques identified by the developers are prioritized in the order of their popularity by using a weighting scheme and their implications are discussed.     

On the automatic classification of app reviews

App stores like Google Play and Apple AppStore have over 3 million apps covering nearly every kind of software and service. Billions of users regularly download, use, and review these apps. Recent studies have shown that reviews written by the users represent a rich source of information for the app vendors and the developers, as they include information about bugs, ideas for new features, or documentation of released features. The majority of the reviews, however, is rather non-informative just praising the app and repeating to the star ratings in words. This paper introduces several probabilistic techniques to classify app reviews into four types: bug reports, feature requests, user experiences, and text ratings. For this, we use review metadata such as the star rating and the tense, as well as, text classification, natural language processing, and sentiment analysis techniques. We conducted a series of experiments to compare the accuracy of the techniques and compared them with simple string matching. We found that metadata alone results in a poor classification accuracy. When combined with simple text classification and natural language preprocessing of the text—particularly with bigrams and lemmatization—the classification precision for all review types got up to 88–92 % and the recall up to 90–99 %. Multiple binary classifiers outperformed single multiclass classifiers. Our results inspired the design of a review analytics tool, which should help app vendors and developers deal with the large amount of reviews, filter critical reviews, and assign them to the appropriate stakeholders. We describe the tool main features and summarize nine interviews with practitioners on how review analytics tools including ours could be used in practice.