Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods

Programming languages and platforms improve over time, sometimes resulting in new language features that offer many benefits. However, despite these benefits, developers may not always be willing to adopt them in their projects for various reasons. In this paper, we describe an empirical study where we assess the adoption of a particular new language feature. Studying how developers use (or do not use) new language features is important in programming language research and engineering because it gives designers insight into the usability of the language to create meaning programs in that language. This knowledge, in turn, can drive future innovations in the area. Here, we explore Java 8 default methods, which allow interfaces to contain (instance) method implementations. Default methods can ease interface evolution, make certain ubiquitous design patterns redundant, and improve both modularity and maintainability. A focus of this work is to discover, through a scientific approach and a novel technique, situations where developers found these constructs useful and where they did not, and the reasons for each. Although several studies center around assessing new language features, to the best of our knowledge, this kind of construct has not been previously considered. Despite their benefits, we found that developers did not adopt default methods in all situations. Our study consisted of submitting pull requests introducing the language feature to 19 real-world, open source Java projects without altering original program semantics. This novel assessment technique is proactive in that the adoption was driven by an automatic refactoring approach rather than waiting for developers to discover and integrate the feature themselves. In this way, we set forth best practices and patterns of using the language feature effectively earlier rather than later and are able to possibly guide (near) future language evolution. We foresee this technique to be useful in assessing other new language features, design patterns, and other programming idioms

Automated Refactoring of Legacy Java Software to Default Methods

Java 8 default methods, which allow interfaces to contain (instance) method implementations, are useful for the skeletal implementation software design pattern. However, it is not easy to transform existing software to exploit default methods as it requires analyzing complex type hierarchies, resolving multiple implementation inheritance issues, reconciling differences between class and interface methods, and analyzing tie-breakers (dispatch precedence) with overriding class methods to preserve type-correctness and confirm semantics preservation. In this paper, we present an efficient, fully-automated, type constraint-based refactoring approach that assists developers in taking advantage of enhanced interfaces for their legacy Java software. The approach features an extensive rule set that covers various corner-cases where default methods cannot be used. To demonstrate applicability, we implemented our approach as an Eclipse plug-in and applied it to 19 real-world Java projects, as well as submitted pull requests to popular GitHub repositories. The indication is that it is useful in migrating skeletal implementation methods to interfaces as default methods, sheds light onto the pattern’s usage, and provides insight to language designers on how this new construct applies to existing software

Towards Improving Interface Modularity in Legacy Java Software through Automated Refactoring

The skeletal implementation pattern is a software design pattern consisting of defining an abstract class that provides a partial interface implementation. However, since Java allows only single class inheritance, if implementers decide to extend a skeletal implementation, they will not be allowed to extend any other class. Also, discovering the skeletal implementation may require a global analysis. Java 8 enhanced interfaces alleviate these problems by allowing interfaces to contain (default) method implementations, which implementers inherit. Java classes are then free to extend a different class, and a separate abstract class is no longer needed; developers considering implementing an interface need only examine the interface itself. We argue that both these benefits improve software modularity, and discuss our ongoing work in developing an automated refactoring tool that would assist developers in taking advantage of the enhanced interface feature for their legacy Java software

Fraglight: Shedding Light on Broken Pointcuts in Evolving Aspect-oriented Software

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is daunting, especially in large and complex systems. We demonstrate an automated tool called FRAGLIGHT that recommends a set of pointcuts that are likely to require modification due to a certain base-code change. The underlying approach is rooted in harnessing unique and arbitrarily deep structural commonality between program elements corresponding to join points selected by a pointcut in a particular software version. Patterns describing such commonality are used to recommend pointcuts that have potentially broken with a degree of confidence as the developer is typing. Our tool is implemented as an extension to the Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to a task

How Many Mutex Bugs Can a Simple Analysis Find in Go Programs?

In open-source software, it is known that there are many concurrency bugs. A previous study in Go revealed that a considerable number of such bugs are simple (for example, 9% of the bugs are the ones that forget to unlock a mutex,) through a manual program investigation. This paper tries to detect such bugs by applying a simple analysis to see how far such a tool can match the manual analysis. We built a simple intraprocedural control flow analysis in Go, and evaluated its performance concerning the open source programs with concurrency bugs reported in the previous study. Consequently, as for quality, the recall is good at 88%, and the precision is poor at 60%; as for analysis time, it can be finished within a practical amount of time (for example, 1 second per 5000 LoC)

Excitation-assisted inelastic processes in trapped Bose-Einstein condensates

We find that inelastic collisional processes in Bose-Einstein condensates induce local variations of the mean-field interparticle interaction and are accompanied by the creation/annihilation of elementary excitation. The physical picture is demonstrated for the case of three body recombination in a trapped condensate. For a high trap barrier the production of high energy trapped single particle excitations results in a strong increase of the loss rate of atoms from the condensate.Comment: 4 pages, no figure

Cold Collision Frequency Shift of the 1S-2S Transition in Hydrogen

We have observed the cold collision frequency shift of the 1S-2S transition in trapped spin-polarized atomic hydrogen. We find $\Delta \nu_{1S-2S} = -3.8(8)\times 10^{-10} n Hz cm^3$, where $n$ is the sample density. From this we derive the 1S-2S s-wave triplet scattering length, $a_{1S-2S}=-1.4(3)$ nm, which is in fair agreement with a recent calculation. The shift provides a valuable probe of the distribution of densities in a trapped sample.Comment: Accepted for publication in PRL, 9 pages, 4 PostScript figures, ReVTeX. Updated connection of our measurement to theoretical wor