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.