The document describes a tool called "Convert Constants to Enum" that automatically converts Java constants to enumerated types. It presents a motivating example of code using constant integers for traffic light and automobile states that could be improved by using enums. The tool is demonstrated converting the example code to use enums, providing benefits like type safety and avoiding issues with the previous "weak enum pattern". The goal is to help developers take advantage of Java 5's new enum features by migrating legacy code.
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  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  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  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  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
 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
 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.
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.
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
Hello. My name is Raffi Khatchadourian from Ohio State University and I am here to discuss the Convert Constants to Enum refactoring tool.
With the emergence of Java’s 1.5 (Tiger) release came a rich set of new features including but not limited to generics, annotations, primitive boxing and unboxing, and the concentration of this work, type-safe enumerations.
Our focus today will be to highlight an automated, semantics-preserving approach based on declarative type inferencing for the migration of legacy Java code (in particular but not limited to 1.4) to take advantage of these new, highly desirable language enumeration constructs.
Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
With the emergence of Java’s 1.5 (Tiger) release came a rich set of new features including but not limited to generics, annotations, primitive boxing and unboxing, and the concentration of this work, type-safe enumerations.
Our focus today will be to highlight an automated, semantics-preserving approach based on declarative type inferencing for the migration of legacy Java code (in particular but not limited to 1.4) to take advantage of these new, highly desirable language enumeration constructs.
Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
With the emergence of Java’s 1.5 (Tiger) release came a rich set of new features including but not limited to generics, annotations, primitive boxing and unboxing, and the concentration of this work, type-safe enumerations.
Our focus today will be to highlight an automated, semantics-preserving approach based on declarative type inferencing for the migration of legacy Java code (in particular but not limited to 1.4) to take advantage of these new, highly desirable language enumeration constructs.
Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
With the emergence of Java’s 1.5 (Tiger) release came a rich set of new features including but not limited to generics, annotations, primitive boxing and unboxing, and the concentration of this work, type-safe enumerations.
Our focus today will be to highlight an automated, semantics-preserving approach based on declarative type inferencing for the migration of legacy Java code (in particular but not limited to 1.4) to take advantage of these new, highly desirable language enumeration constructs.
Oh, and by the way, the tool is currently in progress to be integrated with the standard distribution of Eclipse.
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
An enumerated (enum) type is a data type whose legal values consist of a fixed, closely related set of items known at compile time. They are typically used for comparisons in order to “parameterize” the behavior of the system. Values are commonly distinct from one another and possibly ordered in some preconceived way. And since it was not included up until the release of Java 5, developers, over the years, were forced to use certain “compensation patterns” to represent enum types in Java.
Although several of these compensation patterns exist, here is an instance of a particular pattern, one that has been labeled by the literature as the “standard” way to represent enumerated types in Java 1.4 and below. This pattern has been commonly referred to as the “int enum pattern,” however, since our tool does not discriminate against constants belonging to most primitive types, we will refer to it as the “weak enum pattern.” The term “weak” is used here to denote the pattern’s inherent lack of several key features as I will explain shortly.
Taking a look at our example, here we have a class representing a traffic light signal. The members of the class are as follows. There are three static final constant fields defined, RED, YELLOW, and GREEN, symbolizing the different colors of a traffic signal. Also notice that the constants are ordered akin to the order in which the signals typically appear. We also have a private instance variable called “color” representing the current color the traffic signal is displaying. And lastly, we have an accessor method called “getColor” which simply returns the current value of the preceding instance variable.
Almost immediately apparent is the significant lack of type safety inherent to this pattern. For instance, the field color may receive values from any legal integer outside the set of 0, 1, and 2. Furthermore, operations that are legal for integers may accidentally be applied to colors, such as addition, which may not make a whole lot of sense and possibly produce values outside the intended set of original values.
Another disadvantage of this pattern is that the constants are manually enumerated and its easy to see that such a task is error prone. In particular, a developer may accidentally assign the same value to two different constants unintentionally thereby mistakenly giving the same semantics to two different constants, an error that would not manifest itself until run time.
Yet another drawback is the pattern’s lack of namespacing. That is, by looking at this constant alone, it is unclear as to what RED is referring to. Is it the color of a traffic signal or is it the color of a matador's cape?
Last but not least, the pattern produces constants are brittle, that is, separate compilation is not supported. Since the value of the constant is in-lined into clients at compile time, changing their internal value not only requires recompilation of this class, but also recompilation of all clients. Such a situation would arise during software evolution when perhaps a new constant was to be added in between existing constants.
Now let’s take a look at how we can manually transform this particular instance of the weak enum pattern to instead utilize the new language enumeration constructed provided in Java 5 ...
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
First, let’s remove the static final integer constants and replace them with an equivalent language enumerated type called “Color.”
Next, since we changed the type of the constants and that there is a type dependency with the private instance variable “color,” we must change the declared type of this member from integer to the “Color” enumerated type we declared above.
Of course, since the color field has changed type, its associated assessor method must also be declared to return the new type of this field.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Let’s now examine some of the key features that our new language enumerated type offers over the weak enum pattern instance we saw previously. Notice that our color constants are now associated with their own type, specifically, TrafficSignal.Color.
As a consequence, we have improved the type safety of the code.
Also notice that we have forgone the need to manually enumerate the constants with internal primitive values. Language enumerated types in Java 5 instead utilize the well known “Singleton” pattern where each constant refers to a single memory location in the entire system. Further notice that although the primitive values have disappeared, we have preserved the ordering we had previously bestowed on the constants in that they are now in a so-called “natural” order, that is, they are ordered by the way they are listed in the new type declaration.
Moreover, language enumerated constructs must be properly prefixed by their enclosing type, thereby improving namespace. For instance, we know that red refers to a Traffic Signal color.
And last but not least, since language enumerated constants are reference types, their values, since they are determined at run time, are not in-lined into clients thereby supporting separate compilation.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.
Prior to briefly demoing the tool, let’s go over some of its key features.
One challenge of the refactoring approach is to decide which input constants are participating in an enum compensation pattern and which are not. For example, we don’t want to refactor constants such as PI in the math library.
The tool refactors constants of any primitive type, for example, short, bool, and char. It considers separate semantics preservation constraints for each type.
All code transformations are fully automated. The tool uses class hierarchical analysis to preserve method overriding and overloading.
Has the ability to find and partition each constant into its minimal type dependent set such that changing the type of any one of the constants in the set requires changing the type of all other constants. The current state of the UI unfortunately does not exploit this ability, but we’ll talk more about that in the next slide.
It considers very delicate intricacies of the Java language specification in order to preserve semantics. For example, while the original constants can have varying visibility levels, constants within a language enumeration type must all have the same level. Also, the original constants can share the same primitive value as the new constants will refer to objects that can’t share the same memory space.
Other features include transforming primitive operations like less-than and greater-than to appropriate compareTo() method calls (we’ll see that later as well).
Lastly, it creates the new enum type such that the constants are ordered exactly according to their original primitive value so to preserve comparison semantics.
And above all, it saves the user time and piece of mind by not requiring manual code manipulation and performing all transformations completely and correctly.