Serialize/Deserialize Java enum

[Theodore David Williams]

After two days I finally figured out why (i think) my enum class is not getting deserialzed properly.

   
public enum TestEnum {
   ONE("one"),
   TWO("two"),
   THREE("three";

   private String name;
   private Integer width;
   private Integer length;

   TestEnum(String name) {
      this.name = name;
   }

   public void setWidth(Integer width) {
     this.width = width;
   }

   public void setLength(Integer length) {
     this.length= length;
   }
} 

Now lets say that I programatically set the length and width and serialize to a file.

    
TestEnum t = TestEnum.ONE;
t.setLength(100);
t.setWidth(200);

//Serialize to a file here

If I close my application and try to deserialize, or deserialize from a different application I lose the length and width settings.

My question is this: Is there a way that I can write custom serialize/deserialze code to prevent this behavioir? I.E. override writeObject and readObject? If I can how would I do that?

Thanks in advance!

[Martin Vanyavchich]

Hope this dosen't sound too silly, but shouldn't your enum implement Serializable?

[Theodore David Williams]

It can, but java enums already implement Serializable not no need to re-implement.

From the Java Serialization Spec:

Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not transmitted. To serialize an enum constant, ObjectOutputStream writes the string returned by the constant's name method. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream. The process by which enum constants are serialized cannot be customized; any class-specific writeObject and writeReplace methods defined by enum types are ignored during serialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored--all enum types have a fixed serialVersionUID of 0L.

Is there any way to achieve the behavior I want???

[David Newton]

Not according to your quote.

[Rob Spoor]

Correct. readObject is also not possible since java.lang.Enum implements that to throw an exception. Any attempt to implement this method yourself will fail.

To be honest, I think your design is flawed. Modifiable enums? Really?

[Theodore David Williams]

Rob,

You are correct my design is flawed.

I think what I really wanted after thinking about it is something like this (which works nicely)

   

public class Test  implements Serializable {
   enum TestEnum {  
      ONE("one"),  
      TWO("two"),  
      THREE("three";  
  
      private String name;  

      TestEnum(String name) {  
         this.name = name;  
      }  
   }

   private TestEnum testEnum;
   private Integer width;  
   private Integer length;  
  
   public void setTestEnum(TestEnum testEnum) {
      this.testEnum = testEnum;
   }

   public void setWidth(Integer width) {  
     this.width = width;  
   }  
  
   public void setLength(Integer length) {  
     this.length= length;  
   }  
}   

[Rob Spoor]

I'd make the inner enum coderanch, or it will only be visible from the same package. Unless that's what you want of course.

[Vineet Manohar]

I agree with moving the setter out of Enums, as enums are supposed to be constants. You should not change them once they are created.

As far as serialization is concerned, you should be careful how you serialize the enum value to a database or disk. You should not use the cardinal value or the constant literal to serialize. Use a business value, which is unlikely to change. e.g. "one", "two" in the above example. If interested see my article 3 ways to serialize Java Enums

[Towid Khan]

et al

Enums are automatically serializable and comparable.

here are couple of suggestions that you might want to try out

1. initialize the length and width in the constructor rather than setting them afterwards
2. make the enum public and possibly put it in a different .java file?? -> Good Practice. saves lots valuable time in human lives while figuring out " ?? why ?? "

Regards,
TK

[Paul Draper]

Theodore David Williams wrote:Rob,

You are correct my design is flawed.

I think what I really wanted after thinking about it is something like this (which works nicely)

What you really want is a class with a private constructor and three static instances of that class, ONE, TWO, or THREE

Then serialize those, and reset them during deserialization. No need to cram Enum into something it was never meant to do or be.