> Silly me. :-) Thanks, I fixed it. Indeed the enum classes are now
> implementing the
> Serializable interface.
No, I think you just did us a favor by finding an usability problem.
> > 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?
http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/input.doc6.html#5903
> 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.
Yes, it can be achieved.
> Finally, what good is it to override the "equals" and "hashCode" methods,
> if they just call their Object variants?
To mark them as final so that the derived classes cannot override them.
But the truth is, this is somewhat affected by the JAX-RPC alignment,
and I believe we were just trying to be consistent with them.
regards,
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net