Refactoring for parameterizing Java classes

Type safety and expressiveness of many existing Java libraries and theirclient applications would improve, if the libraries were upgraded to definegeneric classes. Efficient and accurate tools exist to assist clientapplications to use generics libraries, but so far the libraries themselvesmust be parameterized manually, which is a tedious, time-consuming, anderror-prone task. We present a type-constraint-based algorithm forconverting non-generic libraries to add type parameters. The algorithmhandles the full Java language and preserves backward compatibility, thusmaking it safe for existing clients. Among other features, it is capableof inferring wildcard types and introducing type parameters formutually-dependent classes. We have implemented the algorithm as a fullyautomatic refactoring in Eclipse.We evaluated our work in two ways. First, our tool parameterized code thatwas lacking type parameters. We contacted the developers of several ofthese applications, and in all cases where we received a response, theyconfirmed that the resulting parameterizations were correct and useful.Second, to better quantify its effectiveness, our tool parameterizedclasses from already-generic libraries, and we compared the results tothose that were created by the libraries' authors. Our tool performed therefactoring accurately -- in 87% of cases the results were as good as thosecreated manually by a human expert, in 9% of cases the tool results werebetter, and in 4% of cases the tool results were worse

Automatic Refactoring for Renamed Clones in Test Code

Unit testing plays an essential role in software development and maintenance, especially in Test-Driven Development. Conventional unit tests, which have no input parameters, often exercise similar scenarios with small variations to achieve acceptable coverage, which often results in duplicated code in test suites. Test code duplication hinders comprehension of test cases and maintenance of test suites. Test refactoring is a potential tool for developers to use to control technical debt arising due to test cloning. In this thesis, we present a novel tool, JTestParametrizer, for automatically refactoring method-scope renamed clones in test suites. We propose three levels of refactoring to parameterize type, data, and behaviour differences in clone pairs. Our technique works at the Abstract Syntax Tree level by extracting a parameterized template utility method and instantiating it with appropriate parameter values. We applied our technique to 5 open-source Java benchmark projects and conducted an empirical study on our results. Our technique examined 14,431 test methods in our benchmark projects and identified 415 renamed clone pairs as effective candidates for refactoring. On average, 65% of the effective candidates (268 clone pairs) in our test suites are refactorable using our technique. All of the refactored test methods are compilable, and 94% of them pass when executed as tests. We believe that our proposed refactorings generally improve code conciseness, reduce the amount of duplication, and make test suites easier to maintain and extend

Safer typing of complex API usage through Java generics

When several incompatible implementations of a single API are in use in a Java program, the danger exists that instances from different implementations may inadvertently be mixed, leading to errors. In this paper we show how to use generics to prevent such mixing. The core idea of the approach is to add a type parameter to the interfaces of the API, and tie the classes that make up an implementation to a unique choice of type parameter. In this way methods of the API can only be invoked with arguments that belong to the same implementation. We show that the presence of a type parameter in the interfaces does not violate the principle of interface-based programming: clients can still completely abstract over the choice of implementation. In addition, we demonstrate how code can be reused between different implementations, how implementations can be defined as extensions of other implementations, and how different implementations may be mixed in a controlled and safe manner. To explore the feasibility of the approach, gauge its usability, and identify any issues that may crop up in practical usage, we have refactored a fairly large existing API-based application suite, and we report on the experience gained in the process

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

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

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

Automated Refactoring of Legacy Java Software to Enumerated Types

Modern Java languages introduce several new features that offer significant improvements over older Java technology. In this article we consider the new enum construct, which provides language support for enumerated types. Prior to recent Java languages, programmers needed to employ various patterns (e.g., the weak enum pattern) to compensate for the absence of enumerated types in Java. Unfortunately, these compensation patterns lack several highly-desirable properties of the enum construct, most notably, type safety. We present a novel fully-automated approach for transforming legacy Java code to use the new enumeration construct. This semantics-preserving approach increases type safety, produces code that is easier to comprehend, removes unnecessary complexity, and eliminates brittleness problems due to separate compilation. At the core of the proposed approach is an interprocedural type inferencing algorithm which tracks the flow of enumerated values. The algorithm was implemented as an open source, publicly available Eclipse plug-in and evaluated experimentally on 17 large Java benchmarks. Our results indicate that analysis cost is practical and the algorithm can successfully refactor a substantial number of fields to enumerated types. This work is a significant step towards providing automated tool support for migrating legacy Java software to modern Java technologies

Enumeration Refactoring: A Tool for Automatically Converting Java Constants to Enumerated Types

Java 5 introduces several new features that significantly improve older Java technology. We consider the new enum construct, which provides language support for enumerated types. Before Java 5, programmers needed to employ various patterns to compensate for the absence of enumerated types in Java. Unfortunately, these compensation patterns lack several highly desirable properties of the enum construct, notably type-safety. We demonstrate an automated refactoring tool called Convert Constants to Enum for transforming legacy Java code to use the new enumeration construct. An interprocedural type inferencing algorithm that tracks the flow of enumerated values drives the approach, and the tool is implemented as a seamless extension to existing refactoring support in Eclipse. The resulting code is semantically equivalent to the original, increasingly type-safe, easier to comprehend, less complex, and supports separate compilation