7

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!

Nik S
  • 73
  • 1
  • 4
  • 2
    Go with the pojo. See link here for information about `Enum` serialization: http://docs.oracle.com/javase/1.5.0/docs/guide/serialization/relnotes15.html – nattyddubbs Mar 20 '13 at 16:50
  • 1
    One more link about enums serialization http://docs.oracle.com/javase/1.5.0/docs/guide/serialization/spec/serial-arch.html#enum – Vladimir Mironov Mar 20 '13 at 16:57

2 Answers2

8

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.

dfb
  • 13,133
  • 2
  • 31
  • 52
  • 1
    May as well make those fields `final` too if they aren't to be changed. – nattyddubbs Mar 20 '13 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 '13 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 '13 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 '13 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 '13 at 20:16
  • And as you and @yshavit discussed- may be I should not keep it a enum anymore. – Nik S Mar 20 '13 at 20:17
7

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.

McDowell
  • 107,573
  • 31
  • 204
  • 267
  • They don't have to be stateless, they just shouldn't have mutable state. – yshavit Mar 20 '13 at 16:51
  • 1
    @yshavit - Thanks; I've changed the wording to "immutable" to remove any ambiguity. – McDowell Mar 20 '13 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 '13 at 21:20