I have a few questions concerning the use of enumerations. So my understanding is that one of the advantages of enumerations is that they provide compile time type safety in Java, thus making an application more robust. However I find it inconvenient to hard code values in enums. For one, if I need to change an enum I would have to recompile and redeploy my entire application, just because I wanted to add a value. So I thought, why not create the enums at run-time and populate them with data from lookup tables in the database. (As an aside I am not even sure if enums can be generated at run-time) Of course doing so negates the compile time type safety of enums, which makes you wonder why bother using them at all.
Another issue that I can't figure out with enums is how to deal with enum values and internationalization (i18n). If I create an enum for the days of the week, then I would have to generate a separate enum for every language that my application supports. Multiply that by the number of enums used and the number of languages supported and this can quickly become a maintenance headache.
So I would love to get some feedback/discussion from you experts out there. How do you use enums? How do you overcome the question of compile time versus run-time. How do you deal with lookup tables and duplicate, hard-coded enums? How do you handle i18n and enums? Thank you so much for your thoughts.
Enums are really not a solution to i18n issues. You should not define one for days of the week, you should used the existing constants in the Date and Calendar classes. They already have support for locale and other i18n issues.
I'm not seeing any value in having enums in a database. The whole point of them is compile time constants. You don't want them to be run-time defined.
If you had a lot of them that changed in value often, my first suggestion is don't do that.
You could get really fancy and write a bit of code that is run by Ant or Maven when the project is created, but (1) that is not easy and (2) it would slow down the edit/compile/debug cycle.
I use enums for constants, and specifically for "types" For example, I have an enum declared for privileges that users can have, from near powerless rookies, to normal users, special users, administrators, and up to minor gods. I have another set for device characteristics, some user want HTML email, some want plain text.
Pat Farrell wrote:Enums are really not a solution to i18n issues. You should not define one for days of the week, you should used the existing constants in the Date and Calendar classes. They already have support for locale and other i18n issues.
Corect. DateFormatSymbols can already help supply the names of months and weekdays. For i18n that doesn't come with predefined classes to retrieve them the regular i18n mechanism should be used; the Locale could become a parameter to the enum methods.
So if I understand this correctly, if one has i18n concerns and using a database to populate an enum is the wrong approach, there seems to be a very limited set of use cases where an enum is actually useful. For example with an i18n based web site, enums are not useful to display information on the screen. So, can people share for what instances/values people utilize enums? Thanks for the great input so far. This is hugely useful.
They all are short, they just provide nice consistant constants.
There are design decisions behind all of them, some trivial, some more complex. For example,
StatesOfUs has one entry for each of the 50 states in the US. Most lists like this include DC for Washington DC, which is not legally a state. So far, easy. But the US postal address system includes the US Virgin Islands, Guam, and other places scattered all over the world. So you have to decide, do you have 50 values? 51? 55? or the whole list?
This is a domain problem, there is no technically correct solution