RefaFlex

For a quick introduction, there is a teaser video available:

Purpose

RefaFlex is a refactoring engine to refactor reflective Java programs. RefaFlex logs reflective calls during test runs and then uses this information to proactively prevent the programmer from executing refactorings that could otherwise alter the program’s behaviour. RefaFlex can be used to extend most refactoring tool for Java in order to make them reflection safe. As a proof of concept, we extended six of the JDT refactoring tools:

• Rename Field
• Rename Method
• Rename Type
• Rename Package
• Move Type
• Change Method Signature

RefaFlex builds on TamiFlex and Refacola. While we used TamiFlex to collect reflection data, the RefaCola is used to express the constraint rules the refactrings have to obey.

Description

Current refactoring tools for modern IDEs do not offer support for reflection, resulting in changed program semantics when refactoring reflective code. RefaFlex aids in this demand by collecting runtime information from previous test runs and providing a constraint generator giving the programmer valuable information where a refactoring may change a program’s behaviour past refactoring.

This successfully helps to prevent refactorings breaking program behaviour. But there is even more, RefaFlax can do! When renaming a declaration, RefaFlex offers to reflect that rename in the source code to make the given test suites still run past the refactoring.

When moving a declaration, it might get inaccessible for a reflective invocation such that an IllegalAccessException is imminent. RefaFlex can also offer appropriate program transformations for this case.

Limitations

Our implementation actually disregards some corner cases that might occur in context of reflection and refactoring.

• RefaFlex only considers successful calls to the reflection API. A call to the reflection API which e.g., results in an NoSuchFieldException is not considered, but it might change behaviour if a field is moved to the location through which the access was attempted.
• Some methods such as Class#getField(String) use rather uncommon search strategies to determine which declaration object to return if multiple declarations with the same name exist in the given type or one of it’s types. While we correctly consider that the search starts with the given class and continues upwards the super type hierarchy, the reflection API also specifies that super interfaces are searched in the order they are listed within the implements-clauses of the classes they implement. We currently do not guarantee that this ordering is followed correctly. For other methods such as Class#getFields the reflection API does not assure that the returned array has a specific ordering. Several move refactorings will likely change such orderings but RefaFlex will not precent such refactorings.
• Class#getDeclaredField allows to access implicit parameters such as “this$0” which points to the enclosing instance of a non static member class. RefaFlex does not support this (undocumented) feature of the reflection API.
• The Java reflection API also allows accessing Java bridge methods which are sometimes inserted by the compiler to assure correct overriding in context with generic types. RefaFlex also gives no support for such accesses.
• A reflective access to a field via Field#get(Object) might cause this field to get initialized. In Java, a field initializer might contain method invocations having side effects. By moving a reflective field access, it might get initialized later or earlier in the refactored program, possibly causing a change of behaviour.

Downloads & Evaluation Data

We offer for download:

• Our ISSTA'12 paper: RefaFlex: Safer Refactorings for Reflective Java Programs (ACM SIGSOFT Distinguished Paper Award)
• The slides of the ISSTA'12 talk on RefaFlex
• Update: Our poster about RefaFlex
• The TamiFlex Eclipse Plugin (including source code) at the TamiFlex website
• RefaFlex as an Eclipse plugin including extensions to six JDT refactoring tools (including source code)
• The full set of reflection constraint rules implemented in Refacola: ReflectJava.language.refacola and Reflection.rules.refacola
• The TamiFlex logging properties file used for our evaluation
• Links to the benchmark projects used for our evaluation:
• The Play Framework (checkout 2011-07-29)
• Jakarta Commons Collections 4.01 (checkout 2011-07-27)
• Joda Convert 1.1 (checkout 2011-07-27)
• The TamiFlex logs for our benchmark projects:
  • play-refl.log
  • jcc-refl.log
  • joda-refl.log
• The logs from our evaluation on all three benchmark projects

Installation and Operation Guidelines

You may install TamiFlex and RefaFlex by just copying the plugins into your Eclipse’s plugin folder. RefaFlex contributes a page to the Eclipse preferences where you can specify where to look for a TamiFlex log and which refactoring tools to extend. Alike, you may choose whether you like TamiFlex to only add warnings to refactoring dialogs or also like it to contribute code transformations as shown above.

Automatic test runs can be started using the class de.feu.ps.refacola.lang.reflectjava2.rtt.ReflectionRTT. Here, you might want to set additional parameters (e.g., which refactoring tool to test). The ReflectionRTT can also be started using the UI by selecting "Refactoring Tool Test" in the context menu of a Java project.

Team

• Eric Bodden (bodden@st.informatik.tu-darmstadt.de )
• Andreas Thies (andreas.thies@fernuni-hagen.de )