Re: XStream versus XMLEncoder

GArlington wrote:
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 members.

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.
<http://openjpa.apache.org/>)

I'm'a try it myself. Later I'll post something about it, likely not on this thread.

--
Lew
.