Ah, to have been a fly on the wall when they designed Java 5. Imagine a meeting between three unnamed Java language designers:
JLD#1: OK, so, new language features for 5, what’s next on our list? Anyone?
JLD#2: There’s always enums.
JLD#3: Not enums again!
JLD#2: Well, they keep asking for it. It’s getting pretty tiresome. Why don’t we just give them enums, and be done with it? How hard can it be?
JLD#1: OK, let’s consider enums for a minute. How do we do that?
JLD#3: How about we don’t? We’ve already got public static final int.
JLD#1: Just let him talk, OK? We can argue about it later.
JLD#3: All right, whatever.
JLD#2: It’s pretty simple, really. It’s just syntactic sugar. Internally, we implement them as series of public static final ints, but we add code to the compiler that prevents you from assigning or comparing an enum instance with anything else than another instance of the same enum.
JLD#1: Well, that doesn’t sound too bad to me. Any other ideas? Objections?
JLD#3: I really don’t see what it buys us, but if it really is that simple…
JLD#1: OK, we have enough for today. I’ll shop these around, and we meet again next week.
JLD#3: Any donuts left?
JLD#1: All right, picking up from last week. I’ve run our suggestions by management, and they’re OK with most of them, except enums.
JLD#3: Told you…
JLD#2: Shut up and have a donut.
JLD#1: Good idea.
JLD#2: Mmm, jelly.
JLD#1: Anyway, enums. Management feels they’re too… simple. Not enough ROI.
JLD#3: I sure didn’t see that one coming.
JLD#2: What do you mean not enough ROI? They’re just enums! They’ll take a week, max!
JLD#1: They won’t consider a non-trivial language change unless it’s good for at least a couple of pages in the manual and a dozen or so SCJP exam questions. Apparently, it helps sell books and recertifications.
JLD#2: So we scratch enums?
JLD#1: Well, it’s either that, or make them more complicated.
JLD#2: More complicated?
JLD#3: They’re enums for crying out loud!
JLD#1: Any suggestions?
JLD#2: How about… we make an enum a non-instantiable, memberless, final class instead, and each possible value a static instance?
JLD#3: I don’t see how that changes much.
JLD#1: I agree. If anything, it’s actually easier to implement and use. I don’t think management will buy it.
JLD#3: Pass me another donut.
JLD#1: Chocolate or strawberry?
JLD#3: You know me.
JLD#1: Strawberry it is, then. Mind if I have the last one?
JLD#3: By all means.
JLD#2: Pass me a brownie, will you?
JLD#2: So how about… I mean… What if we let them have methods?
JLD#2: You know, methods. Say you have a Colors enum, and someone wants to know what PURPLE smells like?
JLD#3: (eyes brownies suspiciously) Uh-huh…
JLD#2: You’d need a Colors.getSmell() method, right?
JLD#1: I like it.
JLD#3: So an enum is a non-instantiable, memberless, final class with methods and instances…
JLD#2: And variables! There’s not much point in having methods if you don’t have instance variables. They’d all be the same.
JLD#1: Not necessarily. You could subclass them.
JLD#2: That’d be a little weird, having an enum that extends another enum…
JLD#1: Yeah, but you could just have anonymous inner subclasses.
JLD#2: That would really be overkill in simple cases.
JLD#1: So let’s have both!
JLD#3: (stares in disbelief) Both?
JLD#2: Yes! Don’t you see?
JLD#3: So an enum is… a non-instantiable, memberless, final class with subclasses, members and instances?
JLD#3: But that’s just a plain old class!
JLD#1: No, silly! It’s an enum!