Kamil Jezek

Broken promises: An empirical study into evolution problems in Java programs caused by library upgrades

It 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. We have studied the extent of the problem on the qualitas corpus, a data set consisting of Java open-source programs widely used in empirical studies. In this paper, we describe the study and report its key findings. We found that the above mentioned issues do occur in practice, albeit not on a wide scale.

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.

Towards Context Independent Extra-functional Properties Descriptor for Components

Architectures based on composing target application functionality from pre-existing components have been successfully used in many projects, yet there are several aspects in which they fail to reach the desirable level of maturity. Since different vendors may provide components with the same functionality, extra-functional properties must be taken into account to help the developer to select the component which suits the final system. In addition, a selected component must conform to the target deployment environment. This paper addresses the problem of inadequate means to define extra-functional properties on components in a way that allows to express components properties with respect to different computational environments. We provide a representative survey of the current state of the art for extra-functional properties and propose a formalism based on existing approaches which addresses this inadequacy. Our formalism further allows us to use the extra-functional properties for describing the dependency between a component and a deployment environment referred to as deployment contracts. Our approach uses a system of registries that has the advantage of a consistent interpretation of the extra-functional properties found on any given component regardless of its usage context and that separates the semantics and the syntax of each property.

Circular dependencies and change-proneness: An empirical study

Advice that circular dependencies between programming artefacts should be avoided goes back to the earliest work on software design, and is well-established and rarely questioned. However, empirical studies have shown that real-world (Java) programs are riddled with circular dependencies between artefacts on different levels of abstraction and aggregation. It has been suggested that additional heuristics could be used to distinguish between bad and harmless cycles, for instances by relating them to the hierarchical structure of the packages within a program, or to violations of additional design principles. In this study, we try to explore this question further by analysing the relationship between different kinds of circular dependencies between Java classes, and their change frequency. We find that (1) the presence of cycles can have a significant impact on the change proneness of the classes near these cycles and (2) neither subtype knowledge nor the location of the cycle within the package containment tree are suitable criteria to distinguish between critical and harmless cycles.

On the Use of Static Analysis to Safeguard Recursive Dependency Resolution

Modern software systems are not developed from scratch - they rely heavily on the reuse of functionality provided by libraries. Selecting the right libraries remains a challenging task. What is more, libraries themselves often depend on other libraries. Managing these transitive dependencies on libraries is risky. In this paper, we describe the problems that can occur when transitive dependencies are resolved automatically using examples from real-world programs. We then present an empirical study to assess the extent of the problem when the popular Maven tool is used, and propose an approach based on static type checking that can capture many of the problems described at build time.

Detecting Incompatibilities Concealed in Duplicated Software Libraries

Software libraries are currently a popular means to reuse functionality. While they allow for rapid development of large applications, they also bring new challenges. One of them is the selection and composition of the right set of libraries. If it is not done properly, libraries may be incompatible, duplicated or redundant. In this work, we cope with the problem of duplicate libraries and detect situations when a system contains different versions of the same library, one of which should be removed to retain system consistency. These duplicates are detected using an algorithm based on a graph discovery. While this algorithm is generic, we demonstrate its usage specifically on the Java platform with JAR files and in doing so, we provide an experiment showing the scale of the problem on a set of open-source programs.

Supplying Compiler's Static Compatibility Checks by the Analysis of Third-Party Libraries

Statically typed languages and their compile time checks prevent a lot of runtime errors thanks to type mismatches detection, namely calls of incompatible methods. Since current applications typically include tens of already compiled third-party libraries, the compile checks are powerless to detect their mutual dependencies. However, the calls among third-party library methods are not less error prone due to bugs or wrong library usage. These all lead to runtime failures. In this paper, we describe a partial solution to this problem based on the static analysis of third-party libraries and verification of their dependencies. This verification is invoked as the application is compiled and assembled, essentially supplying the compiler detecting errors before the application runs. This approach promises improved error detection of complex applications on the static type checking level.

Lowering Visual Clutter in Large Component Diagrams

Nowadays component applications can easily consist of hundreds or thousands of components and it is thus difficult to understand their structure. Diagram visualisation does not help much because of visual clutter caused by big amount of elements and connections, especially in the case of flat component models. This paper describes a novel approach of removing a large part of connections from the diagram while preserving the information about component interconnections. It uses a separated components area to show the components with big amount of connections. For each component in this area, clustered interfaces are shown instead of all interfaces, with the ability to show details on demand. The main idea of this technique can be used in a similar way to reduce the clutter in node-link graphs. To show the effect of this technique we discuss example lines reductions for several component applications.

What Java developers know about compatibility, and why this matters

Real-world programs are neither monolithic nor static—they are constructed using platform and third party libraries, and both programs and libraries continuously evolve in response to change pressure. In case of the Java language, rules defined in the Java Language and Java Virtual Machine Specifications define when library evolution is safe. These rules distinguish between three types of compatibility—binary, source and behavioural. We claim that some of these rules are counter intuitive and not well-understood by many developers. We present the results of a survey where we quizzed developers about their understanding of the various types of compatibility. 414 developers responded to our survey. We find that while most programmers are familiar with the rules of source compatibility, they generally lack knowledge about the rules of binary and behavioural compatibility. This can be problematic when organisations switch from integration builds to technologies that require dynamic linking, such as OSGi. We have assessed the gravity of the problem by studying how often linkage-related problems are referenced in issue tracking systems, and find that they are common.

Software Components Compatibility Verification Based on Static Byte-Code Analysis

Current enterprise systems are widely implemented using statically typed languages such as Java. One of the reasons are strong type checks at compile time that help prevent runtime errors. The static type checks are also well integrated into current development tools. One of the less explored area are, however, static type checks of binary software components. Since current software usually contains a large amount of third-party components, the compilers can no longer cover the static type checks of the final product, especially the inter-dependencies of the components are out of their reach. In this work, we propose an approach that analyses the byte-code of Java classes to reconstruct the mutual dependencies of respective components first. Then, the dependencies are examined to find any type inconsistencies. As a result, this approach detects dependency problems early in the development phase and prevents undesirable run time product failures caused by them.