Enumeration Refactoring: A Tool for
  Automatically Converting Java
  Constants to Enumerated Types
    Raffi Khatchadouri...
Introduction
Introduction

• Java 5 introduced a rich set of new features such as
  generics, metadata annotations, boxing/unboxing,
  ...
Introduction

• Java 5 introduced a rich set of new features such as
  generics, metadata annotations, boxing/unboxing,
  ...
Introduction

• Java 5 introduced a rich set of new features such as
  generics, metadata annotations, boxing/unboxing,
  ...
Introduction

• Java 5 introduced a rich set of new features such as
  generics, metadata annotations, boxing/unboxing,
  ...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example

                                      Weak Enum
                                       Pattern
class T...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW = 1;
  pub...
Motivating Example Revisited



class TrafficSignal {
  public static final int RED = 0;
  public static final int YELLOW ...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
  public enum Color {RED, RED = 0;
  public s...
Motivating Example Revisited



class TrafficSignal {{
class TrafficSignal
  public enum Color {RED, RED = 0;
  public sta...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
Motivating Example Revisited


                                     Language Enum
class TrafficSignal {{
        TrafficSi...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
Motivating Example Revisited
                      Supports
                      Separate
                     Compilatio...
Motivating Example Revisited



class TrafficSignal {{
        TrafficSignal
class TrafficSignal {
  public enum Color {RE...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
α        '%2"%,&)/ !)&-/ 1)!0#-
  αctxt    30"+$5+ "$ 40"+0 α 1%. Enumerization Approach
                                 ...
Features
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
Features
                                          Math.PI
• Infers which static final fields are being used as
 enums and...
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
• Works...
Features

• Infers which static    final fields are being used as
    enums and which are being used as named constants.
•...
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
• Works...
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
• Works...
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
• Works...
Features

• Infers which static final fields are being used as
 enums and which are being used as named constants.
• Works...
Features

• Infers which static  final fields are being used as
  enums and which are being used as named constants.
• Wor...
Features

• Infers which static  final fields are being used as
  enums and which are being used as named constants.
• Wor...
Features

• Infers which static  final fields are being used as
  enums and which are being used as named constants.
• Wor...
Features

• Infers which static  final fields are being used as
  enums and which are being used as named constants.
• Wor...
Features

• Infers which static  final fields are being used as
  enums and which are being used as named constants.
• Wor...
Current Limitations
Current Limitations


• Still in research prototype stage:
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
   invocation.
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
   invocation...
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
   invocation...
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
   invocation...
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
     invocati...
Current Limitations


• Still in research prototype stage:
 • UI allows for only one enum types creation per
   invocation...
Resources
Resources




• Prototype available at http://code.google.com/p/
 constants-to-enum-eclipse-plugin/
Resources




• Prototype available at http://code.google.com/p/
 constants-to-enum-eclipse-plugin/
• Raffi Khatchadourian...
Upcoming SlideShare
Loading in …5
×

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

1,805 views

Published on

Java 5 introduces several new features that offer significant improvements over 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, most 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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,805
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hello. My name is Raffi Khatchadourian from Ohio State University and I am here to discuss the Convert Constants to Enum refactoring tool.
  • 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.

    Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
  • 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.

    Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
  • 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.

    Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
  • 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.

    Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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 ...
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.







  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
  • Prior to briefly demoing the tool, let’s go over some of its key features.

    One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.

    The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.

    All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.

    Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.

    It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.

    Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).

    Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.

    And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.










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

    1. 1. Enumeration Refactoring: A Tool for Automatically Converting Java Constants to Enumerated Types Raffi Khatchadourian (Ohio State University) Benjamin Muskalla (EclipseSource)
    2. 2. Introduction
    3. 3. Introduction • Java 5 introduced a rich set of new features such as generics, metadata annotations, boxing/unboxing, and type-safe enumerations.
    4. 4. Introduction • Java 5 introduced a rich set of new features such as generics, metadata annotations, boxing/unboxing, and type-safe enumerations. • Overview an automated semantics-preserving type inference approach for migrating legacy Java code to take advantage of the new language enumerated type constructs.
    5. 5. Introduction • Java 5 introduced a rich set of new features such as generics, metadata annotations, boxing/unboxing, and type-safe enumerations. • Overview an automated semantics-preserving type inference approach for migrating legacy Java code to take advantage of the new language enumerated type constructs. • Briefly demonstrate an Eclipse IDE plugin refactoring tool research prototype called CONVERT CONSTANTS TO ENUM.
    6. 6. Introduction • Java 5 introduced a rich set of new features such as generics, metadata annotations, boxing/unboxing, and type-safe enumerations. • Overview an automated semantics-preserving type inference approach for migrating legacy Java code to take advantage of the new language enumerated type constructs. • Briefly demonstrate an Eclipse IDE plugin refactoring tool research prototype called CONVERT CONSTANTS TO ENUM. • In progress to be included with the standard distribution of Eclipse.
    7. 7. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    8. 8. Motivating Example Weak Enum Pattern class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    9. 9. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { Type Safety private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    10. 10. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ Manual private int color = RED; Enumeration /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    11. 11. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ Namespacing public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    12. 12. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; Brittle /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    13. 13. Motivating Example class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    14. 14. Motivating Example Revisited class TrafficSignal { public static final int RED = 0; public static final int YELLOW = 1; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red by default ∗/ private int color = RED; /∗ Accessor for the light’s current color ∗/ public int getColor() {return this.color;}} class Automobile { private static final int IDLE = 0; private static final int INCREASE_SPEED = 1; private static final int DECREASE_SPEED = 2; private static final int STOP = 3;
    15. 15. Motivating Example Revisited class TrafficSignal {{ TrafficSignal public enum Color {RED, RED = 0; public static final int YELLOW, public static final int YELLOW = 1; GREEN}; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public int getColor() {return this.color;}} class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private static final int INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; private static final int MAX_SPEED = 140; private static final int STOP = 3;
    16. 16. Motivating Example Revisited class TrafficSignal {{ class TrafficSignal public enum Color {RED, RED = 0; public static final int YELLOW, public static final int YELLOW = 1; GREEN}; public static final int GREEN = 2; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public int getColor() {return this.color;}} class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private static final int INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; private static final int MAX_SPEED = 140; private static final int STOP = 3;
    17. 17. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    18. 18. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    19. 19. Motivating Example Revisited Language Enum class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    20. 20. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { Type Safety private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    21. 21. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; Singletons in initially red by default */ /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red default */ /* Current color of the traffic signal, colorOrder private ColorNatural = =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    22. 22. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return Prefixed public Color getColor() {return this.color;}} int getColor() {return this.color;}} this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    23. 23. Motivating Example Revisited Supports Separate Compilation class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    24. 24. Motivating Example Revisited class TrafficSignal {{ TrafficSignal class TrafficSignal { public enum Color {RED, RED = 0; public static final int public enum Color {RED, YELLOW, public static final int YELLOW = 1; YELLOW, GREEN}; public static final int GREEN = 2; GREEN}; /∗ Current color of the traffic signal, initially red byby default ∗/ /* Current color of the traffic signal, initially red by default */ /* Current color of the traffic signal, initially red default */ private Color color= =RED; private Color color = Color.RED; private int color Color.RED; /∗ Accessor for the light’s current color */∗/ /* Accessor for the light’s current color */ /* Accessor for the light’s current color public Color getColor(){return this.color;}} public Color getColor() {return this.color;}} int getColor() {return this.color;}} class Automobile { class Automobile { class Automobile { private enum Action {IDLE,IDLE = 0; private enum Action {IDLE, private static final int INCREASE_SPEED, INCREASE_SPEED, private static final int INCREASE_SPEED = 1; DECREASE_SPEED, DECREASE_SPEED, private static final int DECREASE_SPEED = 2; STOP}; STOP}; static final int STOP = 3; private static final int MAX_SPEED = 140; private
    25. 25. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( function E numer iz able(C )P) .',/&4$'& Enumerize(F, 1: >A W ← C /* seed the worklist with the input constants */ R ← Enumerizable(F ) 2: QA N ← ∅ /* the non-enumerizable set ∩ Consistent(R) */ R ← U nique(R) ∩ Distinct(R) list, initially empty 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ ?A &#4 5,' 5: end for 6: while W = ∅ do !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( 7: /* remove an element from the worklist */ 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 6)$-)$! 62#32%1 Contexts(α, P) do 10: for all αctxt ∈ )$!"!")*7 O0"* %**(16!"#$ +#(&- ,) "$'% ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    26. 26. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( Subset of static function E numer iz able(C )P) .',/&4$'& Enumerize(F, final fields 1: >A W ← C /* seed the worklist with the input constants */ R ← Enumerizable(F ) 2: QA N ← ∅ /* the non-enumerizable set ∩ Consistent(R) */ R ← U nique(R) ∩ Distinct(R) list, initially empty 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ ?A &#4 5,' 5: end for 6: while W = ∅ do !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( 7: /* remove an element from the worklist */ 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 6)$-)$! 62#32%1 Contexts(α, P) do 10: for all αctxt ∈ )$!"!")*7 O0"* %**(16!"#$ +#(&- ,) "$'% ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    27. 27. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( function E numer iz able(C )P) Abstract Syntax Tree (AST) .',/&4$'& Enumerize(F, 1: >A W ← C /* seed the worklist with the input constants */ R ← Enumerizable(F ) 2: QA N ← ∅ /* the non-enumerizable set ∩ Consistent(R) */ R ← U nique(R) ∩ Distinct(R) list, initially empty 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ ?A &#4 5,' 5: end for 6: while W = ∅ do !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( 7: /* remove an element from the worklist */ 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 6)$-)$! 62#32%1 Contexts(α, P) do 10: for all αctxt ∈ )$!"!")*7 O0"* %**(16!"#$ +#(&- ,) "$'% ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    28. 28. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( function E numer iz able(C )P) .',/&4$'& Enumerize(F, Output: C /* seed the worklist with the input constants */ 1: >A W ← Enumerizable(F ) R← 2: QA N ← ∅ /* the non-enumerizable set ∩ Consistent(R) */ R ← U nique(R) ∩ Distinct(R) list, initially empty 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ ?A &#4 5,' 5: end for 6: while W = ∅ do !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( 7: /* remove an element from the worklist */ 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 6)$-)$! 62#32%1 Contexts(α, P) do 10: for all αctxt ∈ )$!"!")*7 O0"* %**(16!"#$ +#(&- ,) "$'% ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    29. 29. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( function E numer iz able(C )P) .',/&4$'& Enumerize(F, Output: C /* seed the worklist with the input constants */ 1: >A W ← Enumerizable(F ) R← •2: QA NR← ∅U nique(R) ∩ Distinct(R) ∩ Consistent(R) */ Partitioning of program entities: list, initially empty ← /* the non-enumerizable set 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do • Fields T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ 5: • end for declarations (return types) ?A Method &#4 5,' 6:• while W = ∅ do (including formal parameters) Local variables !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( 7: /* remove an element from the worklist */ 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 6)$-)$! 62#32%1 Contexts(α, P) do 10: for all αctxt ∈ )$!"!")*7 O0"* %**(16!"#$ +#(&- ,) "$'% ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    30. 30. α '%2"%,&)/ !)&-/ 1)!0#- αctxt 30"+$5+ "$ 40"+0 α 1%. Enumerization Approach #++(2 !"#$%& '( !)%*+,"-* .)/+/").( function E numer iz able(C )P) .',/&4$'& Enumerize(F, Output: C /* seed the worklist with the input constants */ 1: >A W ← Enumerizable(F ) R← •2: QA NR← ∅U nique(R) ∩ Distinct(R) ∩ Consistent(R) */ Partitioning of program entities: list, initially empty ← /* the non-enumerizable set 3: GAfor all c T ∈ R 4, 5,' *22 ∈ C do • Fields T ransf orm(T ) 4: RA MakeSet(c) /* init the union-find data structure */ 5: • end for declarations (return types) ?A Method &#4 5,' 6:• while W = ∅ do (including formal parameters) Local variables !"#$%& 0( 1)23,&4&, &.$*&%"5+/"). +,#)%"/6*( /* remove an element from the worklist */ • Each partition contains elements that: 7: 2)9%+!#2"$37 e M)W 8: α ← e | ∈ %&*# %**(1) !0%! 4) %2) %,&) !# *!%!"+% • Transitively type-dependent upon one another W ← W {α} "-)$!"9. %&& 2)9)2)$+)* !# +%$-"-%!) !)&-* %$- !2%$*"!"')&. - 9: 10:• Are all αctxt ∈ Contexts(α, P) do 6)$-)$!safe for enum type transformation +#(&- ,) "$'% for 62#32%1 )$!"!")*7 O0"* %**(16!"#$ ¬isEnumerizableContext (α, αctxt ) then -%!)-if!02#(30 !0) (*) #9 2)")+!"#$ %$- +(*!#1 +&%** &#%-) 11:
    31. 31. Features
    32. 32. Features • Infers which static final fields are being used as enums and which are being used as named constants.
    33. 33. Features Math.PI • Infers which static final fields are being used as enums and which are being used as named constants.
    34. 34. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values.
    35. 35. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. short, bool, char, etc.
    36. 36. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated.
    37. 37. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. Uses CHA to preserve polymorphism
    38. 38. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set.
    39. 39. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set. Correctly partitions all input constants
    40. 40. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set. • Preserves semantics by considering intricacies of the Java language specification and primitive to reference type conversion.
    41. 41. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set. • Preserves semantics by considering intricacies of the Java language specification and primitive to reference type conversion. • Converts primitive operations to method calls.
    42. 42. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set. • Preserves semantics by considering intricacies of the Java language specification and primitive to reference type conversion. • Converts primitive operations to method calls. • Preserves natural ordering.
    43. 43. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal types such that changing one constant requires changing all constants in the set. • Preserves semantics by considering intricacies of the Java language specification and primitive to reference type conversion. For comparison • Converts primitive operations to method calls. preservation • Preserves natural ordering.
    44. 44. Features • Infers which static final fields are being used as enums and which are being used as named constants. • Works with all primitive values. • Transformation is fully automated. • Infers minimal typestime and piece of one constant Saves such that changing requires changing all constants in the set. mind! • Preserves semantics by considering intricacies of the Java language specification and primitive to reference type conversion. • Converts primitive operations to method calls. • Preserves natural ordering.
    45. 45. Current Limitations
    46. 46. Current Limitations • Still in research prototype stage:
    47. 47. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation.
    48. 48. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation. • UI does not allow user to split constants into smaller enum types.
    49. 49. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation. • UI does not allow user to split constants into smaller enum types. • No renaming of constants.
    50. 50. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation. • UI does not allow user to split constants into smaller enum types. • No renaming of constants. • Enum type name inference only based on longest common prefix.
    51. 51. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation. • COLOR_RED, UI does not allow user to split constants into smaller COLOR_GREEN, ...results enum types. in enum Color • No renaming of constants. • Enum type name inference only based on longest common prefix.
    52. 52. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation. • UI does not allow user to split constants into smaller enum types. • No renaming of constants. • Enum type name inference only based on longest common prefix. • Limited undo support.
    53. 53. Resources
    54. 54. Resources • Prototype available at http://code.google.com/p/ constants-to-enum-eclipse-plugin/
    55. 55. Resources • Prototype available at http://code.google.com/p/ constants-to-enum-eclipse-plugin/ • Raffi Khatchadourian, Jason Sawin, and Atanas Rountev. Automated refactoring of legacy Java software to enumerated types. In Proceedings of the 23rd International Conference on Software Maintenance (ICSM ’07), pages 224–233, Paris, France, October 2007. IEEE.

    ×