Comments on: 3 ways to serialize Java Enums

By: Eric Richardson

Eric Richardson — Wed, 28 Apr 2010 18:47:55 +0000

What problem are you trying to solve by using different approaches? The loss of a key.
You are trying to prevent unintended disconnect between a key and a value in an off-line data structure (database table or flat file). None of your solutions do that.

It is like taking a foreign key, embedding it in a string and dropping the string in a column. Later when you return parse the string, extract the key, lookup the key and find you have broken referential integrity you have no one to blame but yourself.

If you are using a database, create a legal value table and put a real foreign key constraint. XML with a schema can use an enumeration.

Use the right tool for the right job.

By: Leo Hart

Leo Hart — Fri, 22 Jan 2010 14:46:38 +0000

We use something similar to example 3 with a Hibernate UserType. Now we have a requirement to create lookups for all our enum values in our database. Not sure if there’s a simple way to do that…

By: vineet

vineet — Wed, 20 Jan 2010 01:08:55 +0000

Jeremy, you have a fair point. I agree that the difference is just one level of indirection, but a very useful one. It moves the persisted value from the “developer space” to “business space”. I think the change in “business-value” will come from business stakeholders and not the developer and that is what makes approach 3 the most robust, at the cost of simplicity. I use approach 3 most of the times, and approach 2 when I am working on a one person project and I know that I will not change the constant name.

I agree that if theoretically enum constant is dramatically changed, then the divergence between enum name and business-value could be confusing. I just think that it is an uncommon case, the more common case is minor tweaks in the name by the developer, adding/removing underscores, uppercase/lowercase/camelcase modifications.

By: Jeremy

Jeremy — Tue, 19 Jan 2010 23:40:04 +0000

Your problem with approach 2 above is that a developer could change the name of the enum, from “GREEN” to “Green” in your example. But surely the same could happen with your preferred “business-value” approach ie. the developer could just as easily change the business-value as he could the enum name?

While approach 3 may give a level of indirection, I think in the long run having a divergence between the enum name and business-value could just end up being more problematic.

By: vineet

vineet — Tue, 19 Jan 2010 16:13:54 +0000

Rafael, can you elaborate why providing a setter (or mutator) method for colorValue field will break the implementation?

By: Rafael Alvarez

Rafael Alvarez — Tue, 19 Jan 2010 15:28:43 +0000

I concur with Joerg that this is the perfect case for the Hibernate UserType. As soon as someone provides a mutator for the colorValue field, hell will break loose.

And that can happen if you want hibernate to use accessors for the attributes instead of modifying directly the fields.

By: vineet

vineet — Tue, 19 Jan 2010 14:25:01 +0000

Could you describe or provide a use case how approach 3 is error prone.

By: vineet

vineet — Tue, 19 Jan 2010 14:22:15 +0000

Using name() has the drawback that I mentioned. If the developer renames the enum constant, you won’t be able to retrieve the old value.

By: Joerg Wassmer

Joerg Wassmer — Tue, 19 Jan 2010 12:54:35 +0000

Your approach 3 is pretty error prone. You should use a Hibernate UserType to do the mapping automatically.

By: chandra

chandra — Tue, 19 Jan 2010 12:50:52 +0000

good 1