Difficult to be sure, but there is something about that approach which doesn't seem quite right. Just a feeling . . .
You are going to find it very difficult to alter the code of the enum whenever you add another make of car. It just doesn't feel quite right to me. It might be that you are constraining the enum and the table to each other when each ought to be a primary data type.
Well, it's possible to do this, sure. The main question I would ask is whether you really want to be forced to update the code every time the table changes. It may be that the table really won't change very often, OK. Or it may be that you really do need to have a complete list of all possible values in your code, regardless of how often you need to change it - in which case this might be a good way to unsure it's in sync. But when I did this sort of thing a few years ago (before enums were in the language - I used the enumerated type pattern from Effective Java instead) it proved to be a lot more work than it was worth. Most of my code didn't really need to know what the values were; it just needed to know that the value was a legal value. So the actual enum constants were rarely if ever used, and the effort involved in changing the code every time the database changed was a lot more than was really worthwhile. Your situation may be different, but it's worth thinking about.
[Sharon]: How do I implement the same logic to other system enums without cloning the code?
With an enum you can't extend another class, so I would probably create a static helper method to minimize the code you need in each new enum:
Note that while you can't have an enum extend another class, you can have it implement an interface. So if you have any standard methods that you want all your DB constant enums to implement, you can declare an interface for them. Alternately you may find it useful to create a DbConstants annotation, to facilitate some sort of automatic build processes that check your build tables under certain circumstances - e.g. create a functional test that is run for any class annotated with @DbConstant.
Like Campbell above, I'm not sure this is a good path to go down; I'm just tossing out possible implementation ideas.
Originally posted by Sharon whipple: Hi Paul, i was wandering in your java code how do you use symbolic/constant tables like "Car_Manufacturer"
I don't. Those are database tables in our systems, not code. And if there was supposed to be different behaviour (say we couldn't send warranty claims to Volvo) we would put a column into the car manufacturer table (in this case "AcceptsClaims"). That's why I asked what you planned to do with those enum values.