This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Where do you package your enums? I generally have a package called model which contains my POJOs, JavaBeans, whatever you want to call them. I have a Size class which contains a reference to an Enum of measurements (inches, cm, etc). It makes the most sense to me to package the enum under the model package, but at the same time feels kind of lost.
I put them in the same package as my model classes as well. It seems to me to be the most logical place, because the model classes are where the enums are used, and the set of constants in an enum is information about the data model - so it belongs in the model package.
Sometimes I have an enum as a static inner class inside a model class. I do this if the enum values are very specific to that model class (if they should not be used in a context other than for that specific model class). One example that I found in my source code: I have a class that represents information about a transaction, and the transaction has a status: OPEN or CLOSED. Because this status is very specific to this class, I've defined it as an inner enum in the class:
I don't think there's anything special about enums that would require a special place for them. I don't keep interfaces in a different place from classes, for example. Their location should be based on what other entities they relate to. In most cases that's probably model classes, more specifically in whatever subpackage contains most of the classes that use the enum. And if that's really just one class (or one class is clearly more inextricably entwined with the enum than any other) then making it a static nested enum makes sense. Alternately in some cases you may have an enum or set of enums that are used in many different packages, in which case they may deserve a package of their own. E.g. com.bolinger.units for the units of measurement in your example. Such a package needn't be just enums though. It could have classes, interfaces, etc too if you have any that fit in with units of measurement. So yes, I basically agree with both of you. I don't see any need to "'feel kind of lost" about it - sounds like you're doing the right thing here. [ April 23, 2008: Message edited by: Jim Yingst ]