Comments on: 3 ways to serialize Java Enums

By: James Hogue

James Hogue — Thu, 05 Jan 2012 14:19:02 +0000

You don’t actually need to mark that as @Transient. You’re not supposed to mix method and field annotations in Hibernate so since you’re not actually saving the Color to a field, you don’t need to mark that method as @Transient, which is probably why it worked for apalam. If you saved Color off to a field, it would make sense to then mark the field as @Transient.

By: vineet

vineet — Fri, 09 Sep 2011 21:23:48 +0000

When you serialize a bean, serializers typically ignore any fields marked as @Transient. You don’t want to store values for fields which are computed. In this case the idea is to only serialize “colorValue” but not Color which is computed from colorValue.

Even if you are not serializing, it is a good practice (IMO) to mark computed fields as @Transient. It makes the code very readable, telling the reader at a quick glance which fields hold information and which fields are computed from other fields.

By: apalam

apalam — Fri, 09 Sep 2011 21:16:18 +0000

Excellent!!
You have in fact spelled something that is not spelled anywhere – ORMs by default use name.

Could you clarify why is the transient annotation on the getter required? My code is working fine without it. JPA with Hibernate
– Apalam

By: Anonymous

Anonymous — Wed, 31 Aug 2011 06:00:06 +0000

java enums are simply great . I have seen a lot many functionality covered by enum but serialization of enum looks new to me but indeed if you are going to store values in database than this is one of the best way.

By: Raghu

Raghu — Wed, 06 Jul 2011 03:23:59 +0000

Excellent !!! I was thinking of implementing the same, luckily found the site.

By: SoftwareFads

SoftwareFads — Fri, 01 Jul 2011 20:50:55 +0000

Method 3 is the simplest, shortest and easiest way I have seen to persist enums in Hibernate. It is way less verbose than creating a UserType class, which is the “official” Hibernate solution for enums. Hibernate is a very, very verbose system, requiring endless lines of annotations or XML configuration files. Frankly, Hibernate stinks on ice if it is used in any real world project with even a moderate level of complexity.

By: simon

simon — Thu, 05 May 2011 14:50:10 +0000

your third solution, while i see the versatility advantage, is waaaaaay too verbous.

By: vineet

vineet — Mon, 14 Mar 2011 15:26:34 +0000

Hi, Bernhard – that would work.

My point was that the constant literal value (e.g. RED, GREEN) is a value in the developer realm and should not be directly related to values which are persisted. The expectation of developers is that simply renaming a constant like Color.GREEN should not affect old saved data, which I think it is a reasonable expectation. To me that is not too different than someone telling me that I cannot rename a method because that could break previously persisted data.

By: Bernhard H.

Bernhard H. — Mon, 14 Mar 2011 15:14:59 +0000

Maybe it would be the best solution to assign some kind of a enumSerialVersionUID to your enum and store this along with your values. That way, if you modify the constant names (and you know what serialVersionUIDs are) you’d maybe have the old keys persisting in the database, but you can find and transform them. The enumSerialVersionUID has the advantage that it reminds of a standardized behaviour for serializable obejcts, so it’s a little more obvious in contrast to some business values, isn’t it?

By: Towid Khan

Towid Khan — Mon, 07 Mar 2011 18:57:17 +0000

Yup. that is what I meant. While I am on this topic. I have just came up with an idea to make your approach#3 stronger. Why don’t we use a tuple as a key;the String Name along with identifiers to identify the base enum type?

That is,

RED(“RED”,Color.Class)
BLUE(“BLUE”,Color.Class)

or use random integer in case of class value?

The motivation behind this is that the developer does not know the exact key and hence cannot change it. of course there is a challenge to map the class type to SQL data type. but Hibernate worry about that