This past summer I went to Google IO and listened to the performance talk. I didn't like what Colt had to say about enums, so I wrote a blog post about it. I like to think I started all of the annoying enum discussion, though I'm not sure how accurate that is. Regardless, my post received many thousands of views, generated good discussion, and even received a comment from one of the creators of Java enums!
I want to put the issue to rest, so I'm writing a brief part 2. The Android team talked about the "enum problem" at the latest Android Dev Summit and seemed much more reasonable:
Here are some key points:
- Understand the cost of everything, make decisions off that. Don't do things blindly.
- The Android Framework itself uses enums.
- Measure everything.
- Beware death by a thousand cuts. It can be costly to refactor out enums later if there is a performance problem.
- Google's public APIs are conservative because they don't know what types of apps we are making. That doesn't mean you need to be conservative.
- If you're making a library, think very carefully about using things like that, because you're making a policy decision on behalf of your users.
- If you're making a typical app, it probably doesn't matter.
This closely matches my previous views. Start with enums, continuously measure, use something different if needed for performance. Hopefully this closes the case.