Future Endeavors in Automated Refactoring of Legacy Java Software to Enumerated Types

Editor's Notes

• #2: Today I will be discussing an automated approach to refactoring legacy Java software to utilize the new Java enumerated type language construct. This is joint work Jason Sawin and Dr. Atanas Rountev at the Ohio State University and is supported in part by the NSF.
• #4: Changing a method to accommodate a new parameter requires changing the method declaration for each method in the type hierarchy, examining other methods in the hierarchy to assure they are not being overridden, and altering each method invocation site scattered throughout the source code. HashMap iterator is fail-safe while Hashtable enumerator isn't. If you change the map while iterating, you'll know.
• #6: With the emergence of Java’s 1.5 (Tiger) release came a rich set of new features including but not limited to generics, annotations, primitive boxing and unboxing, and the concentration of this work, type-safe enumerations. Our focus today will be to highlight an automated, semantics-preserving approach based on declarative type inferencing for the migration of legacy Java code (in particular but not limited to 1.4) to take advantage of these new, highly desirable language enumeration constructs. I will then proceed to discuss some experimental results from a research prototype of the tool on 17 large Java applications. Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
• #7: An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java. Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly. Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable. Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values. Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time. Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape? Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants. Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
• #8: First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.” Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above. Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
• #9: Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color. As a consequence, we have improved the type safety of the code. Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration. Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color. And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
• #10: Now that we have altered our Traffic Signal class to take advantage of the new language enumerated types offered in Java 1.5, let’s consider clients of the traffic signal class. What sorts of changes should be propagated to these clients? Here is a simple example where client code must be examined. Here we have an “Automobile” class that is a client of “Traffic Signals.” It has a method named “react” that takes a reference to a traffic signal as input and returns the appropriate action this automobile should take dependent upon the color of the signal. So, let’s take a look at the contexts in which the signal is used. Here’s a call to the signal’s color access method that appears in a switch statement. One nice, new feature of the enum construct is that it is compatible with switch statements. That is, previously, only integral types were allowed inside the switch expression, however, in Java 1.5, expressions evaluating to an enum type are also allowed, thus allowing for a more general switch statement. Of course, we must also ensure that each case expression evaluates to one of three colors we defined earlier before we can do any transformation. From a refactoring point of view, one stipulation is that the case statements inherit the namespace of the switch expression, so we must remove the prefix from each case statement. As I mentioned earlier, the react method returns an automobile action that should be taken by this automobile dependent upon the color of the traffic single. Interestingly, the set of “automobile actions” constitute another, separate enum type participating in the weak enum pattern. Moving further up the automobile class, we see that automobile actions are similarly declared. Also notice that there’s another constant named “MAX_SPEED” which has an almost identical declaration as the automobile actions above it, however, the connotation of this constant is very different from that of automobile actions. MAX_SPEED is what is known as a “named constant,” its a symbolic name for a particular threshold value. Another example of a named constant is java.lang.PI. You can imagine that such a value would appear in various mathematical operations which would not be directly compatible with enum types. As for MAX_SPEED In this context, is being used to denote the maximum acceleration of the automobile. As we will see, we don’t want to refactor these sorts of constants, and that distinguishing between these kinds of entities presents itself as one of the key challenges of an automated approach. Just as we did for the traffic signal class, let’s examine the code for type dependent entities of our automobile actions. Here we see a instance variable named “currentAction” which is intended to represent the current action the automobile is performing. We see that it receives its value from one of the constants so we’ll mark this entity as “promising” in that it potentially could take on an enum type. We’ll have to further examine type dependent entities of “currentAction” in order to say for sure. Here’s an example of an instance variable with a very similar declaration as the entity above, however, we definitely do not want to refactor this field as it is meant to represent the current acceleration of the automobile. Thus, its “internal value” has a very precise meaning and we do not want to remove from the code. Now that we have identified another promising enum type, we more to our second category of contexts in which these entities appear, specifically return statements. Due to this context, notice that signatures should change. Furthermore, the type of the field current action should change since it is a possible return value.
• #11: Let’s now examine the changes required to transform automobile actions into language enumeration types. Since we are returning “Actions” we must now alter the return type of the method signature. Doing so requires further investigation as we will see shortly. The other changes are simpler in that we only need to add a prefix to each constant. Notice that the field “currentAction” does not change since its declared type has already been altered as well as the appropriate method signature. That’s one thing that’s nice about this refactoring, the original source is type correct once the declarations of the entities that have been considered “safe” for enumerization has changed. I’ll discuss what it means for a program entity to be considered safe next.
• #13: We use a union-find data structure to track entity dependencies and to form the partitions.
• #14: Adaptation of a classic declarative type inferencing algorithm inductively defined in the Java grammar. Here is a snippet of the formalization of our algorithm.
• #16: Groups them into minimal sets s.t. each set must share the same enum type. Natural ordering by original primitive values in order to preserve comparability semantics.
• #17: Column uses shows the total number of declaration sites that must be modified to accommodate the enumerization.
• #18: See technical report for a complete list of filtered contexts.
• #19: 13% needs more sophisticated primitive value analysis.
• #20: Native array copying requires more sophisticated tracking of entities.