> The problem is you didn't specify:
>
> jaxb:extensionBindingPrefixes="xjc"
Silly me. :-) Thanks, I fixed it. Indeed the enum classes are now
implementing the
Serializable interface.
> > If the class is serializable, then == won't work as expected and
> > custom hashCode() and equals() methods are required. See the following
example.
> The point I was trying to make is that the singleton/serialization problem
> should be solved by the readResolve method, not by changing the semantics
> of the singleton.
> In any case, when <xjc:serializable /> is activated, I confirmed that this
> works correctly.
I can't follow you here. First of all, I can see that a "readResolve" method
is indeed generated, but it is private and not referenced. What good is it?
Besides, I disagree in the semantics. I can feel, that it is *desirable* to
have == the same than "equals", but fact is that this cannot be achieved for
serializable objects. My personal feeling is, that at least "equals" should
work as expected. I am sure that this is common sense (though not too many
people may be listening right now).
Finally, what good is it to override the "equals" and "hashCode" methods,
if they just call their Object variants?
Regards,
Jochen