SlideShare une entreprise Scribd logo
1  sur  55
Enumeration Refactoring: A Tool for
  Automatically Converting Java
  Constants to Enumerated Types
    Raffi Khatchadourian (Ohio State University)
         Benjamin Muskalla (EclipseSource)
Introduction
Introduction

• Java 5 introduced a rich set of new features such as
  generics, metadata annotations, boxing/unboxing,
  and type-safe enumerations.
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.
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.
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.
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;
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;
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;
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;
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;
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;
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;
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;
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;
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;
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
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
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
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
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
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
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
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
α        '%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:
α        '%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:
α        '%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:
α        '%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:
α        '%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:
α        '%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:
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 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 with all primitive values.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
 • UI does not allow user to split constants into smaller
   enum types.
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.
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.
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.
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.
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, 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.

Contenu connexe

Tendances

jQuery Visual Cheat Sheet (by WOORK)_1
jQuery Visual Cheat Sheet (by WOORK)_1jQuery Visual Cheat Sheet (by WOORK)_1
jQuery Visual Cheat Sheet (by WOORK)_1brecke
 
VHDL- gate level modelling
VHDL- gate level modellingVHDL- gate level modelling
VHDL- gate level modellingVandanaPagar1
 
No more loops with lambdaj
No more loops with lambdajNo more loops with lambdaj
No more loops with lambdajMario Fusco
 
VIT351 Software Development VI Unit1
VIT351 Software Development VI Unit1VIT351 Software Development VI Unit1
VIT351 Software Development VI Unit1YOGESH SINGH
 
Unlocking the Magic of Monads with Java 8
Unlocking the Magic of Monads with Java 8Unlocking the Magic of Monads with Java 8
Unlocking the Magic of Monads with Java 8JavaDayUA
 
From Function1#apply to Kleisli
From Function1#apply to KleisliFrom Function1#apply to Kleisli
From Function1#apply to KleisliHermann Hueck
 
Esoft Metro Campus - Certificate in java basics
Esoft Metro Campus - Certificate in java basicsEsoft Metro Campus - Certificate in java basics
Esoft Metro Campus - Certificate in java basicsRasan Samarasinghe
 
Java 8 - An Overview
Java 8 - An OverviewJava 8 - An Overview
Java 8 - An OverviewIndrajit Das
 
DIWE - Programming with JavaScript
DIWE - Programming with JavaScriptDIWE - Programming with JavaScript
DIWE - Programming with JavaScriptRasan Samarasinghe
 
Introduction to Erlang Part 2
Introduction to Erlang Part 2Introduction to Erlang Part 2
Introduction to Erlang Part 2Dmitry Zinoviev
 
SeneJug java_8_prez_122015
SeneJug java_8_prez_122015SeneJug java_8_prez_122015
SeneJug java_8_prez_122015senejug
 
The SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse
The SOUL Tool Suite for Querying Programs in Symbiosis with EclipseThe SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse
The SOUL Tool Suite for Querying Programs in Symbiosis with EclipseCoen De Roover
 
Esoft Metro Campus - Programming with C++
Esoft Metro Campus - Programming with C++Esoft Metro Campus - Programming with C++
Esoft Metro Campus - Programming with C++Rasan Samarasinghe
 

Tendances (17)

jQuery Visual Cheat Sheet (by WOORK)_1
jQuery Visual Cheat Sheet (by WOORK)_1jQuery Visual Cheat Sheet (by WOORK)_1
jQuery Visual Cheat Sheet (by WOORK)_1
 
Interface in java
Interface in javaInterface in java
Interface in java
 
VHDL- gate level modelling
VHDL- gate level modellingVHDL- gate level modelling
VHDL- gate level modelling
 
No more loops with lambdaj
No more loops with lambdajNo more loops with lambdaj
No more loops with lambdaj
 
VIT351 Software Development VI Unit1
VIT351 Software Development VI Unit1VIT351 Software Development VI Unit1
VIT351 Software Development VI Unit1
 
Unlocking the Magic of Monads with Java 8
Unlocking the Magic of Monads with Java 8Unlocking the Magic of Monads with Java 8
Unlocking the Magic of Monads with Java 8
 
Functions
FunctionsFunctions
Functions
 
From Function1#apply to Kleisli
From Function1#apply to KleisliFrom Function1#apply to Kleisli
From Function1#apply to Kleisli
 
Esoft Metro Campus - Certificate in java basics
Esoft Metro Campus - Certificate in java basicsEsoft Metro Campus - Certificate in java basics
Esoft Metro Campus - Certificate in java basics
 
Java 8 - An Overview
Java 8 - An OverviewJava 8 - An Overview
Java 8 - An Overview
 
DIWE - Programming with JavaScript
DIWE - Programming with JavaScriptDIWE - Programming with JavaScript
DIWE - Programming with JavaScript
 
Introduction to Erlang Part 2
Introduction to Erlang Part 2Introduction to Erlang Part 2
Introduction to Erlang Part 2
 
DIWE - Fundamentals of PHP
DIWE - Fundamentals of PHPDIWE - Fundamentals of PHP
DIWE - Fundamentals of PHP
 
SeneJug java_8_prez_122015
SeneJug java_8_prez_122015SeneJug java_8_prez_122015
SeneJug java_8_prez_122015
 
Monadic Java
Monadic JavaMonadic Java
Monadic Java
 
The SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse
The SOUL Tool Suite for Querying Programs in Symbiosis with EclipseThe SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse
The SOUL Tool Suite for Querying Programs in Symbiosis with Eclipse
 
Esoft Metro Campus - Programming with C++
Esoft Metro Campus - Programming with C++Esoft Metro Campus - Programming with C++
Esoft Metro Campus - Programming with C++
 

Plus de Raffi Khatchadourian

Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...
Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...
Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...Raffi Khatchadourian
 
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Raffi Khatchadourian
 
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...Raffi Khatchadourian
 
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...Raffi Khatchadourian
 
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...Raffi Khatchadourian
 
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...Raffi Khatchadourian
 
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Raffi Khatchadourian
 
An Empirical Study on the Use and Misuse of Java 8 Streams
An Empirical Study on the Use and Misuse of Java 8 StreamsAn Empirical Study on the Use and Misuse of Java 8 Streams
An Empirical Study on the Use and Misuse of Java 8 StreamsRaffi Khatchadourian
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsSafe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsRaffi Khatchadourian
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsSafe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsRaffi Khatchadourian
 
A Brief Introduction to Type Constraints
A Brief Introduction to Type ConstraintsA Brief Introduction to Type Constraints
A Brief Introduction to Type ConstraintsRaffi Khatchadourian
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...Raffi Khatchadourian
 
A Tool for Optimizing Java 8 Stream Software via Automated Refactoring
A Tool for Optimizing Java 8 Stream Software via Automated RefactoringA Tool for Optimizing Java 8 Stream Software via Automated Refactoring
A Tool for Optimizing Java 8 Stream Software via Automated RefactoringRaffi Khatchadourian
 
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...Raffi Khatchadourian
 
Towards Safe Refactoring for Intelligent Parallelization of Java 8 Streams
Towards Safe Refactoring for Intelligent Parallelization of Java 8 StreamsTowards Safe Refactoring for Intelligent Parallelization of Java 8 Streams
Towards Safe Refactoring for Intelligent Parallelization of Java 8 StreamsRaffi Khatchadourian
 
Proactive Empirical Assessment of New Language Feature Adoption via Automated...
Proactive Empirical Assessment of New Language Feature Adoption via Automated...Proactive Empirical Assessment of New Language Feature Adoption via Automated...
Proactive Empirical Assessment of New Language Feature Adoption via Automated...Raffi Khatchadourian
 
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Raffi Khatchadourian
 
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Raffi Khatchadourian
 
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...Raffi Khatchadourian
 
Poster on Automated Refactoring of Legacy Java Software to Default Methods
Poster on Automated Refactoring of Legacy Java Software to Default MethodsPoster on Automated Refactoring of Legacy Java Software to Default Methods
Poster on Automated Refactoring of Legacy Java Software to Default MethodsRaffi Khatchadourian
 

Plus de Raffi Khatchadourian (20)

Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...
Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...
Towards Safe Automated Refactoring of Imperative Deep Learning Programs to Gr...
 
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
 
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...
A Tool for Rejuvenating Feature Logging Levels via Git Histories and Degree o...
 
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...
Challenges in Migrating Imperative Deep Learning Programs to Graph Execution:...
 
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...
Actor Concurrency Bugs: A Comprehensive Study on Symptoms, Root Causes, API U...
 
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...
An Empirical Study of Refactorings and Technical Debt in Machine Learning Sys...
 
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
Automated Evolution of Feature Logging Statement Levels Using Git Histories a...
 
An Empirical Study on the Use and Misuse of Java 8 Streams
An Empirical Study on the Use and Misuse of Java 8 StreamsAn Empirical Study on the Use and Misuse of Java 8 Streams
An Empirical Study on the Use and Misuse of Java 8 Streams
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsSafe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 StreamsSafe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams
 
A Brief Introduction to Type Constraints
A Brief Introduction to Type ConstraintsA Brief Introduction to Type Constraints
A Brief Introduction to Type Constraints
 
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...
Safe Automated Refactoring for Intelligent Parallelization of Java 8 Streams ...
 
A Tool for Optimizing Java 8 Stream Software via Automated Refactoring
A Tool for Optimizing Java 8 Stream Software via Automated RefactoringA Tool for Optimizing Java 8 Stream Software via Automated Refactoring
A Tool for Optimizing Java 8 Stream Software via Automated Refactoring
 
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...
Porting the NetBeans Java 8 Enhanced For Loop Lambda Expression Refactoring t...
 
Towards Safe Refactoring for Intelligent Parallelization of Java 8 Streams
Towards Safe Refactoring for Intelligent Parallelization of Java 8 StreamsTowards Safe Refactoring for Intelligent Parallelization of Java 8 Streams
Towards Safe Refactoring for Intelligent Parallelization of Java 8 Streams
 
Proactive Empirical Assessment of New Language Feature Adoption via Automated...
Proactive Empirical Assessment of New Language Feature Adoption via Automated...Proactive Empirical Assessment of New Language Feature Adoption via Automated...
Proactive Empirical Assessment of New Language Feature Adoption via Automated...
 
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
 
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...Defaultification Refactoring: A Tool for Automatically Converting Java Method...
Defaultification Refactoring: A Tool for Automatically Converting Java Method...
 
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...
Automated Refactoring of Legacy Java Software to Default Methods Talk at ICSE...
 
Poster on Automated Refactoring of Legacy Java Software to Default Methods
Poster on Automated Refactoring of Legacy Java Software to Default MethodsPoster on Automated Refactoring of Legacy Java Software to Default Methods
Poster on Automated Refactoring of Legacy Java Software to Default Methods
 

Dernier

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoffsammart93
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...Martijn de Jong
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CVKhem
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobeapidays
 
Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024The Digital Insurer
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc
 
Advantages of Hiring UIUX Design Service Providers for Your Business
Advantages of Hiring UIUX Design Service Providers for Your BusinessAdvantages of Hiring UIUX Design Service Providers for Your Business
Advantages of Hiring UIUX Design Service Providers for Your BusinessPixlogix Infotech
 
Data Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonData Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonAnna Loughnan Colquhoun
 
Tech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfTech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfhans926745
 
HTML Injection Attacks: Impact and Mitigation Strategies
HTML Injection Attacks: Impact and Mitigation StrategiesHTML Injection Attacks: Impact and Mitigation Strategies
HTML Injection Attacks: Impact and Mitigation StrategiesBoston Institute of Analytics
 
Exploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone ProcessorsExploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone Processorsdebabhi2
 
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024Rafal Los
 
AWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAndrey Devyatkin
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Drew Madelung
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Scriptwesley chun
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdfhans926745
 
Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Enterprise Knowledge
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024The Digital Insurer
 
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationFrom Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationSafe Software
 
GenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdfGenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdflior mazor
 

Dernier (20)

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CV
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
 
Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
 
Advantages of Hiring UIUX Design Service Providers for Your Business
Advantages of Hiring UIUX Design Service Providers for Your BusinessAdvantages of Hiring UIUX Design Service Providers for Your Business
Advantages of Hiring UIUX Design Service Providers for Your Business
 
Data Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonData Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt Robison
 
Tech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfTech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdf
 
HTML Injection Attacks: Impact and Mitigation Strategies
HTML Injection Attacks: Impact and Mitigation StrategiesHTML Injection Attacks: Impact and Mitigation Strategies
HTML Injection Attacks: Impact and Mitigation Strategies
 
Exploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone ProcessorsExploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone Processors
 
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024
 
AWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of Terraform
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Script
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
 
Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024
 
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationFrom Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
 
GenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdfGenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdf
 

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

  • 1. Enumeration Refactoring: A Tool for Automatically Converting Java Constants to Enumerated Types Raffi Khatchadourian (Ohio State University) Benjamin Muskalla (EclipseSource)
  • 3. Introduction • Java 5 introduced a rich set of new features such as generics, metadata annotations, boxing/unboxing, and type-safe enumerations.
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. α '%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. α '%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. α '%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. α '%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. α '%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. α '%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:
  • 32. Features • Infers which static final fields are being used as enums and which are being used as named constants.
  • 33. Features Math.PI • Infers which static final fields are being used as enums and which are being used as named constants.
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  • 46. Current Limitations • Still in research prototype stage:
  • 47. Current Limitations • Still in research prototype stage: • UI allows for only one enum types creation per invocation.
  • 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. 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. 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. 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. 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.
  • 54. Resources • Prototype available at http://code.google.com/p/ constants-to-enum-eclipse-plugin/
  • 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.

Notes de l'éditeur

  1. Hello. My name is Raffi Khatchadourian from Ohio State University and I am here to discuss the Convert Constants to Enum refactoring tool.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 ...
  7. An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java. Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly. Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable. Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values. Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time. Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape? Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants. Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
  8. 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 ...
  9. 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 ...
  10. 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 ...
  11. 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 ...
  12. 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 ...
  13. 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 ...
  14. 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 ...
  15. 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 ...
  16. 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 ...
  17. 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 ...
  18. 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 ...
  19. 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 ...
  20. 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 ...
  21. 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 ...
  22. 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 ...
  23. 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 ...
  24. 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 ...
  25. 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 ...
  26. 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 ...
  27. 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 ...
  28. 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 ...
  29. 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 ...
  30. 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 ...
  31. 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 ...
  32. 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 ...
  33. 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 ...
  34. 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 ...
  35. 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 ...
  36. 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 ...
  37. 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 ...
  38. 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 ...
  39. 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 ...
  40. 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 ...
  41. 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 ...
  42. 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.
  43. 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.
  44. 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.
  45. 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.
  46. 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.
  47. 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.
  48. 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.
  49. 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.
  50. 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.
  51. 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.
  52. 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.
  53. 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.
  54. 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.
  55. 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.
  56. 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.
  57. 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.
  58. 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.
  59. 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.
  60. 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.
  61. 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.
  62. 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.
  63. 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.
  64. 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.
  65. 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.
  66. 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.
  67. 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.
  68. 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.
  69. 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.
  70. 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.
  71. 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.
  72. 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.
  73. 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.
  74. 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.
  75. 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.
  76. 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.
  77. 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.
  78. 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.
  79. 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.
  80. 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.
  81. 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.
  82. 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.
  83. 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.
  84. 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.
  85. 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.
  86. 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.
  87. 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.
  88. 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.
  89. 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.
  90. 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.
  91. 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.
  92. 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.
  93. 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.
  94. 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.
  95. 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.
  96. 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.
  97. 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.