enum vs static final String
I was going to use static final Strings as enumerated constants in my application, but would like to see if I should be using enums instead.
In terms of efficiency, if I have, say, 5 enumerated elements, will only one copy of the enumerated element be in memory, like a static final String? So regardless of how many times I refer to it, all references point to the same instance (I'm not sure if what I just said even makes sense in the context of enums, but perhaps you could clarify).
Are there any reasons why for enumerated constants that are known at development time, why static final Strings (or static final anything, for that matter) should be used instead of enums if you're using JDK 1.5?
Thanks.
> In terms of efficiency, if I have, say, 5 enumerated elements, will only one copy of
> the enumerated element be in memory, like a static final String?
I don't know if it addesses your concerns, but the the Java Language Specification says this about enums: "It is a compile-time error to attempt to explicitly instantiate an enum type (?5.9.1). The final clone method in Enum ensures that enum constants can never be cloned, and the special treatment by the serialization mechanism ensures that duplicate instances are never created as a result of deserialization. Reflective instantiation of enum types is prohibited. Together, these four things ensure that no instances of an enum type exist beyond those defined by the enum constants." (http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9)
As for the problems of memory usage, how big are these strings anyway?
The advantages of using enums over static final strings are discussed in the "technotes" accompanying 1.5 http://java.sun.com/javase/6/docs/technotes/guides/language/enums.html They list the following as problems with the static final "antipattern"
* It is not typesafe (methods that expect one of your constants can be sent any old string)
* There is no name space - so you must continually be sure that your constants don't have names that may be confused
* Brittleness. Your strings will be compiled into the clients that use them. Then later you add a new constant...
?nbsp; * Printed values will be uninformative. Perhaps less of a problem for Strings, but, still, simply printing the string will leave its semantic significance obscure.
> In terms of efficiency, if I have, say, 5 enumerated
> elements, will only one copy of the enumerated
> element be in memory, like a static final String? So
> regardless of how many times I refer to it, all
> references point to the same instance (I'm not sure
> if what I just said even makes sense in the context
> of enums, but perhaps you could clarify).
First, you shouldn't make your app design dependant on the notion of saving 50 bytes.
Second, why would a static enumerated constant *not* be a constant like any others? It would just complicate matters.
> Are there any reasons why for enumerated constants
> that are known at development time, why static final
> Strings (or static final anything, for that matter)
> should be used instead of enums if you're using JDK
> 1.5?
None I know, except code compatibility with 1.4.
> ?* It is not typesafe (methods that expect one
> of your constants can be sent any old string)
Typesafe it is - it's still a String. But no value range defined.
> ?* Brittleness. Your strings will be compiled
> into the clients that use them. Then later
> you add a new constant...
You always need to add handling code for the new constant though. That doesn't change when adding a new enum parameter.
> ?* Printed values will be uninformative.
> Perhaps less of a problem for Strings, but, still,
> simply printing the string will leave its semantic
> significance obscure.
And how is System.out.println(INT_CONST) different from System.out.println(enum.CONST)? Both might be 143, and neither helps.
> >* Printed values will be uninformative.
> > Perhaps less of a problem for Strings, but, still,
> > simply printing the string will leave its semantic
> > significance obscure.
> And how is System.out.println(INT_CONST) different from
> System.out.println(enum.CONST)? Both might be 143, and neither helps.
Both might be 143 - that is to say an instance of an enum type might have the value 143 associated with it - although simple enum types don't need to have their instances associated with values. Even in this case what's printed (via the default toString()) will be different for the enum and the static final int:public class PrintEnum {
enum Const {
Int(143);
private final int value;
Const(int v) {
value = v;
}
};
static final int INT = 143;
public static void main(String[] args) {
System.out.println(INT); // prints "143"
System.out.println(Const.Int);// prints "Int"
}
}
> > ?* It is not typesafe (methods that expect one> > of your constants can be sent any old string)> > Typesafe it is - it's still a String. But no value> range defined.Typesafe, but not value-safe.
jverda at 2007-7-12 18:58:48 >
There's lots of reasons why enum are to be preferred. You can be sure only one instance of each value exists, so each enum variable costs you a one-slot reference.
But consider that you can switch() on enums. Consider the power of EnumSet and EnumMap (which essentially allows you to use an enum as the subscript of an array). Consider that you can always compare with == not equals (which is substantially slower for strings).
And if you want to make it easy to print friendly value strings, you can add a toString() method to each value.
> ?* Brittleness. Your strings will be compiled
> into the clients that use them. Then later
> you add a new constant...
Thanks for your response. Could you explain the brittleness part again? With enums, if you add a new constant don't you have to compile the client again?
[200th post!]
