Thoughts on Refactoring Sequential Java Code for Concurrency via Concurrent Libraries

This paper is regarding semi-automatic refactoring support for Java programs. It takes advantage of the java.util.concurrent package available in Java 5 and the FrontJoinTask framework in Java 7. The authors present a tool, Concurrencer that enables users to transform a sequential program to parallel via converting int to AtomicInteger, HashMap to ConcurrentHashMap, and Recursion to ForkJoinTask.

In the paper, one major sell point for this tool is that it does not need user annotation. However, this tool being semi-automatic means that it still requires manual inspection to identify the places in the code for transformation. Nevertheless, it is useful. As the authors have pointed out, manual refactoring is error-prone; having a tool to do the busy work should be a lot safer provided that it does the work correctly.

One factor that influences whether a programmer chooses to use a refactoring tool is trust. When a programmer uses a tool, he or she loses control. Thus, it is very important that he can comprehend the automatic refactoring being done. Out of the three types of refactoring Concurrencer provides, the first two a programmer should have no problems understand but the last one may not be obvious. It is very likely that a programmer needs to go through the changed code in detail just to make sure it is correct. Thus, although the authors advertises the LOC that the tool saves the programmer from typing, in reality it may not save time. Saying that, it does help if complete automatic unit tests are available to verify or if the programmer reads this paper beforehand to understand the ForkJoin conversion. The trust level will build up gradually over time.