Library developers who have to evolve a library to accommodate changing requirements often face a dilemma: Either they implement a clean, efficient solution but risk breaking client code, or they maintain compatibility with client code, but pay with increased design complexity and thus higher maintenance costs over time. We address this dilemma by presenting a lightweight approach for evolving application programming interfaces (APIs), which does not depend on version control or configuration management systems. Instead, we capture API refactoring actions as a developer evolves an API. Users of the API can then replay the refactorings to bring their client software components up to date. We present CatchUp!, an implementation of our approach that captures and replays refactoring actions within an integrated development environment semi-automatically. Our experiments suggest that our approach could be valuable in practice.

In the course of a framework’s evolution, changes ranging from a simple refactoring to a complete rearchitecture can break client programs. Finding suitable replacements for framework elements that were accessed by a client program and deleted as part of the framework’s evolution can be a challenging task. We present a recommendation system, SemDiff, that suggests adaptations to client programs by analyzing how a framework adapts to its own changes. In a study of the evolution of the Eclipse JDT framework and three client programs, our approach recommended relevant adaptive changes with a high level of precision, and detected non-trivial changes typically undiscovered by current refactoring detection techniques.

Abstract—Applications built on reusable component frameworks are subject to two independent, and potentially conflicting, evolution processes. The application evolves in response to the specific requirements and desired qualities of the application’s stakeholders. On the other hand, the evolution of the component framework is driven by the need to improve the framework functionality and quality while maintaining its generality. Thus, changes to the component framework frequently change its API on which its client applications rely and, as a result, these applications break. To date, there has been some work aimed at supporting the migration of client applications to newer versions of their underlying frameworks, but it usually requires that the framework developers do additional work for that purpose or that the application developers use the same tools as the framework developers. In this paper, we discuss our approach to tackle the API-evolution problem in the context of reuse-based software development, which automatically recognizes the API changes of the reused framework and proposes plausible replacements to the “obsolete ” API based on working examples of the framework code base. This approach has been implemented in the Diff-CatchUp tool. We report on two case studies that we have conducted to evaluate the effectiveness of our approach with its Diff-CatchUp prototype. Index Terms—Software reuse, API evolution, model differencing, software migration. 1

Since annotations were added to the Java language, many frameworks have moved to using annotated Plain Old Java Objects (POJOs) in their newest releases. Legacy applications are thus forced to undergo extensive restructuring in order to migrate from old framework versions to new versions based on annotations (Version Lock-in). Additionally, because annotations are embedded in the application code, changing between framework vendors may also entail largescale manual changes (Vendor Lock-in). This paper presents a novel refactoring approach that effectively solves these two problems. Our approach infers a concise set of semantics-preserving transformation rules from two versions of a single class. Unlike prior approaches that detect only simple structural refactorings, our algorithm can infer general composite refactorings and is more than 97 % accurate on average. We demonstrate the effectiveness of our approach by automatically upgrading more than 80K lines of the unit testing code of four open-source Java applications to use the latest version of the popular JUnit testing framework.

Software frameworks and libraries are indispensable to today’s software systems. As they evolve, it is often timeconsuming for developers to keep their code up-to-date, so approaches have been proposed to facilitate this. Usually, these approaches cannot automatically identify change rules for one-replaced-by-many and many-replaced-by-one methods, and they trade off recall for higher precision using one or more experimentally-evaluated thresholds. We introduce AURA, a novel hybrid approach that combines call dependency and text similarity analyses to overcome these limitations. We implement it in a Java system and compare it on five frameworks with three previous approaches by Dagenais and Robillard, M. Kim et al., and Schäfer et al. The comparison shows that, on average, the recall of AURA is 53.07% higher while its precision is similar, e.g., 0.10 % lower. 1.

its execution to account for contention in the environment. Similarly, for maximum performance an application must be able to adapt itself to the structure of the data as it evolves throughout the execution of the application. 2 Coping with the Problem: An Example from Scientific Computing One example where the performance requirements imposed by dynamism are most evident is in scientific and engineering computing, which encompasses particle simulations, stock market predictions, weather forecasting, drug design, and product engineering. The scientific computing community has turned to concurrency (i.e., parallelism) in response to the need for maximum performance. The language approach: High Performance Fortran. An important focus for this community has been the development of improved programming languages to address the tension between performance and backward compatibility, both of which are vital in a rapidly changing environment. The High Perfor

In the development of software, architecture has been conceptualized largely as a fully preplanned and imposed structure. However, planning is so difficult in our chaotic world that successful software projects must continually adapt to the shifting conditions of technology and the market. Consequently, software projects must admit the need to restructure their systems to introduce structure as needed as well as find architecture where none was seen before. By delaying the introduction of costly architecture, software projects can get to market more quickly, developing a customer base to fund future architectural efforts and providing much neededfeedback on what architecture would be appropriate. 1 Problem: Planning in an Uncertain World Our technologyinfrastructure hasbecomeso highly evolvedthat the changes it induces are perceptible daily. Change is now so rapid and unpredictable that it is nearly impossible to perform effective longterm planning. A business's commitment to a partic...

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. Our goal is to reduce the burden of reuse on maintenance by reducing the cost of adapting to change. We studied the API changes of five components and discovered that over 80 % of the changes that break existing applications are refactorings. This suggests that refactoring-based migration tools should be used to effectively upgrade applications. We propose a methodology to automatically and safely upgrade component-based application with no overhead on the component producers. 1 Problem Description Part of maintaining a software system is updating it to use the latest version of its components. Developers like to reuse software components because it lets them build a system more quickly, but then the system depends on the components

API evolution is the process of migrating an inter-library interface from one version to another. Such a migration requires checking that all libraries which interact through the interface be updated. Libraries can be updated one by one if there is a transition period during which both updated and non-updated libraries can communicate through some transitional version of the interface. Static type checking can verify that all libraries have been updated, and thus that a transition period may end and the interface be moved forward safely. Anti-deprecation is a novel type-checking feature that allows static checking for more interface evolutions periods. Anti-deprecation, along with the more familiar deprecation, is formally studied as an extension to Featherweight Java. This formal study unearths weaknesses in two widely used deprecation checkers. “In Java when you add a new method to an interface, you break all your clients.... Since changing interfaces breaks clients you should consider them as immutable once you’ve published them. ” –Erich Gamma [21] “NoSuchMethodError ” –Java VM, all too frequently 1. OVERVIEW Libraries communicate with each other via application programming interfaces (API’s), or interfaces for short. The key idea with interfaces is that so long as a set of libraries conform to their interfaces, those libraries will tend to function together when they are combined. This approach is a key part of standard discussions of software modularity [2]. This interfaces idea supports independent evolution of li-This is an extended version of a workshop paper [19].

In the course of a framework’s evolution, changes ranging from a simple refactoring to a complete rearchitecture can break client programs. Finding suitable replacements for framework elements that were accessed by a client program and deleted as part of the framework’s evolution can be a challenging task. We present a recommendation system, SemDiff, that suggests adaptations to client programs by analyzing how a framework adapts to its own changes. In a study of the evolution of the Eclipse JDT framework and three client programs, our approach recommended relevant adaptive changes with a high level of precision, and detected non-trivial changes typically undiscovered by current refactoring detection techniques.