Re: XStream versus XMLEncoder
1) The presence of default (no arguments) c(onstruc)tor does not stop
the class/bean being safe, you can always define a call to default
initialising method from it. I tend to have constructors for every
eventuality (all possible combinations of init parameters) and have
them all call main initialising method with all parameters setting the
defaults to those not passed to the particular c(onstuc)tor.
2) In case of handling messages maybe you do not need setters, because
you do not change the values of the message, but again, there is no
harm in having it.
The problem with having setters, required for a class with a no-arg
constructor when you want to set values of private members, is that you cannot
make the members final. The advantage of constructors with arguments is that
they let you make the members final.
The complaint about having to use setters is that it prevents the use of final
One workaround might be to have a wrapper object, with setters, that is
actually a builder. When it detects that it has complete state, it delegates
to an immutable object with the same properties, and returns that immutable
object thenceforth. It will also throw a RuntimeException
(IllegalStateException would suit) on any attempt to call a setter once the
immutable object is built. Likewise on any attempt to use the object prior to
completion of the properties.
I'm suggesting this and it seems like a hack to me. Still it might help the
impedance mismatch between things that require setters and things you want to
be immutable. (I get this with JSF a lot, and JPA won't even let you declare
the accessors and mutators as final, although it seems that OpenJPA does.
I'm'a try it myself. Later I'll post something about it, likely not on this