I read this weeks JavaLobby newsletter and I noticed another post by Shai about JDK 5 features. More of a rant than a post about how the JDK 5 features suck and all that. I disagree that the features suck but agree the implementation is lacking. JDK 5 could really have done some wonderful things with the JVM if they choose not to use erasure for generics, but that’s my only main gripe. Other than that I think most of the features are fine. I use most of them and enjoy them a lot.

One thing he mentioned was that enums were a bad idea. He didn’t give solid claims as to why they were and asked for folks to post why they were a good idea. I’ve done some posting on enums in the past and I figured I’d take a stab at it.

Let’s think objectively about enums. I haven’t really done this to this point and my previous posts had a bit lacking because I forgot this step. What are they trying to accomplish? Model a fix set of values that does not ever change, right? Why a fixed set? First and foremost because without a fixed set a whole suite of problems arises including the serialization issue I discussed in this post. Adding new enum values is not backwards compatible. Let’s walk through an example.

Example: axis (3D axis)

Axes are a fixed set and could easily be an enum. What’s the JDK 1.4- solutions? Flyweight, ints, and Strings.

Okay, here are the issues with these:

Flyweight

• These are pretty much the same as enums if they are final and have all the extra methods
• In fact you could create static values and you have a type-safe enum JDK 1.4 style
• They are serializable, fixed, and can have additional functionality added to them

ints

• Require a static somewhere to store the mapping (public static final int Y_AXIS = 1;)
• Not type safe because methods that use the enum must take ints. If X_AXIS = 0, Y_AXIS = 1 and Z_AXIS = 2 I can still pass a method 42
• You can’t add functionality without a helper class – like converting them to strings or looking them up by strings or whatever
• If you encapsulate the constants and helper methods into a single class, you’ve almost made a type safe enum and might as well finish the task and get the type safety

Strings

• Same as ints and they can’t be compared using the enums natural ordering without additional methods, harder to compare for equality

Okay, so if you abide by the contract of enums being a fixed set, I’m not sure I see the issue. You shouldn’t be able to sub-class them (that would make them NOT a fixed set), you can add functionality, compare them, they are type safe, can have additional attributes, which only the fly-weight solution from JDK 1.4 shares, and they can be compared directly.

I’m interested as to what the major objection to this is? If it’s that it is more syntax to an already complex language, than it really has nothing to do with enums but more the syntax of JDK 5 as a whole. If it is anything else, feel free to leave me comments. I’m very interested to hear what people feel is wrong with this pattern. Oh and stating issues when enums aren’t fixed sets is probably not a good idea. I know there a lots of issues with non-fixed set enums, but that’s a modelling problem, not a problem with the language construct.