Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 5 down vote favorite
1

I have a Java Enum as shown below:

public enum ExecutionMode {
  TYPE_A,
  TYPE_B,
  TYPE_C;

  private ExecutionMode(){} //no args constr- no really required

  private boolean incremental; //has get/set
  private String someStr;      //has get/set
}

I see that after deserialization, the custom fields on the enum are lost. On reading more about it, I got the impression that enum gets deserialized into a string and hence its custom fields are ignored.

If its true, am I abusing Enum here & should just use POJO istead? Or is there a way to serialize the custom fields (that are not part of the constructor)?

Thanks!

share|improve this question
2  
Go with the pojo. See link here for information about Enum serialization: docs.oracle.com/javase/1.5.0/docs/guide/serialization/… – nattyddubbs Mar 20 at 16:50
One more link about enums serialization docs.oracle.com/javase/1.5.0/docs/guide/serialization/spec/… – vmironov Mar 20 at 16:57

2 Answers

up vote 5 down vote accepted

If the values are constant, this is better and you don't need to serialize anything

public enum ExecutionMode {
  TYPE_A(x,t),
  TYPE_B(y,z),
  TYPE_C(b,s)

  private boolean incremental; //has get/set
  private String someStr;      //has get/set

  ExecutionMode(boolean incremental,String someStr){
        ///... set things appropriately
  } 
}

If you're setting these values at runtime, my inclination would be that this shouldn't be an enum in the first place - there should be a separate POJO that perhaps contains the values as well as a reference to an enum value.

share|improve this answer
1  
May as well make those fields final too if they aren't to be changed. – nattyddubbs Mar 20 at 16:49
I wonder if this approach (with setters) would mean that the serialized enum would not contain the latest values of incremental or someStr, but instead be serialized with the defaults. – yshavit Mar 20 at 16:51
1  
@yshavit - It won't hold the state. If you're using setters outside of the enum, it shouldn't be an enum. – dfb Mar 20 at 16:52
That's what I would have assumed, @dfb. I suspect that's not what the OP wants, based on the original question. If it is, the OP would have provided that constructor and not had a setter. – yshavit Mar 20 at 16:53
Thanks @dfb. Thats exactly how I'd defined the enum, but now there are changes were the custom fields have to be made mutable. – Nik S Mar 20 at 20:16
show 1 more comment
up vote 3 down vote

From the Java language specification:

The final clone method in Enum ensures that enum constants can never be cloned, and the special treatment by the serialization mechanism ensures that duplicate instances are never created as a result of deserialization. Reflective instantiation of enum types is prohibited. Together, these four things ensure that no instances of an enum type exist beyond those defined by the enum constants.

What you are asking for would create more than one instance of, say, TYPE_A. This would break enums. Enums should be immutable.

share|improve this answer
They don't have to be stateless, they just shouldn't have mutable state. – yshavit Mar 20 at 16:51
1  
@yshavit - Thanks; I've changed the wording to "immutable" to remove any ambiguity. – McDowell Mar 20 at 16:53
Thanks @McDowell & yshavit - I think "They don't have to be stateless, they just shouldn't have mutable state." probably sums it up! – Nik S Mar 20 at 21:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.