Mohsen Vakilian's Blog

February 15, 2009

OOPSLA 2008–Annotation Refactoring

Filed under: evolution,refactoring — mohsenvakilian @ 12:27 am

Annotation refactoring is a refactoring by demonstration system to upgrade Java programs to use annotations. The example which the paper focuses on is JUnit. JUnit introduced some annotations in version 4 and annotation refactoring can be used to upgrade tests written using JUnit 3 to use JUnit 4. The authors try not to limit the tool to JUnit by inferring the transformations from a given example of upgrading a class. First, the differences between the two given versions of the class are computed. Then, the transformation is inferred and represented in a domain specific language which can be corrected and refined by the user.

The addressed problem is important and there are still more opportunities to improve the accuracy of the inferencer.  Upgrading programs to JUnit is a simple case of annotation refactoring and handling more complex Java frameworks will be challenging.


OOPSLA 2008–Sound and Extensible Renaming for Java

Filed under: refactoring — mohsenvakilian @ 12:05 am

Sound and extensible renaming addresses the difficulty of coming up with a correct implementation of the rename refactoring in Java. The presenter did a good job of motivating the audience at OOPSLA. At the beginning of his talk, he showed several examples of Java programs causing all major Java IDE’s to fail in performing the rename refactoring correctly. The authors mention two reasons for complexity of the rename refactoring:

  1. addition of new constructs to the Java language
  2. complex name lookup

They introduce a systematic way to ensure that the binding structure of the program is maintained when the refactoring is applied. In addition, they claim their approach is modular and thus easy to be extended to support new constructs of the Java language.
They have implemented the so called inverted lookup functions in JastAdd. By implementing the inverted lookup function corresponding to each lookup function, they claim no corner cases are missed and thus the binding structure is kept unchanged. While performing the rename refactoring, it might be necessary to replace some names by their fully qualified names. Some existing Java IDE’s abort the refactoring in such cases because of too strong preconditions. In their approach, they let the user perform the refactoring by automatically replacing a name by its fully qualified name if necessary.

Their paper demonstrates how tricky it is to implement the rename refactoring correctly. However, I still think there are some easier ways to fix the problem. Most IDE’s such as Eclipse can list all references of a particular variable. This means they can easily build the binding structure of the program. If we compare the binding structures before and after the refactoring we can prevent performing a rename refactoring which changes the binding structure.

The paper addresses an important problem and it might be possible to solve some deficiencies of other refactorings similarly.

Create a free website or blog at