Re: XStream versus XMLEncoder

On Dec 5, 2:45 pm, ap...@xxxxxxxxxxxxxxxxxx wrote:
On 5 Dec, 11:45, GArlington <garling...@xxxxxxxxxxxxx> wrote:



On Dec 4, 9:58 pm, ap...@xxxxxxxxxxxxxxxxxx wrote:

Hello,

I have to send and receive messages using a JMS queue and have decided
to use XML to represent the messages. I have a class for each message
type (a couple of requests and a couple of replies). These classes
employ ctors that initialize the private members and there are getters
for each private data member. There are no setters and no default
ctor. I am currently using XStream. This allows me to convert an
object to an XML String and an XML String back to the object. It is
working just fine.

However, a colleague pointed out that there is a mechanism that comes
as std with java now that can be used to do the same job, XMLEncoder.
The code to serialize and deserialize is just as simple as it is with
XStream except that certain requirements are placed on the class being
serialized. It must be a bean, which means it only handles those
private data members for which there are getters and SETTERS and there
must be a default ctor. This has put me off XMLEncoder since my
classes have no need of these things. Also I regard a default ctor as
more dangerous than one that inits all the members, since it is
possible to use the default ctor then forget to call ALL the setters
that are required to fully init the object. Also it seems to me that I
would have to make my objects beans to use XMLEncoder and they would
otherwise not be beans since there is no other need for them to be.
They are not taking part in web pages or JSP or anything like that,
they just get written to and read from JMS queues.

Which do people think should be used? I want to use std components
where possible and the trouble with XStream is it means adding a
couple of jars to the project which already has loads. XMLEncoder is
at least standard so no new jars should be needed. But I do not like
the requirements it places on the classes to be serialized. Did
XStream come along before there was XMLEncoder? Does XMLEncoder mean
than XStream is no longer needed?

Comments please. I am still quite new to java and have no experience
of beans. I need some guidance.

Regards,

Andrew Marlow

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 disagree. Of course it is possible to set any variable to some sort
of default and to do this in the default ctor. But the value will
still be wrong if it is not later set to a proper value by the setter
method. This makes it possible to have an object in an invalid state.
Maybe not invalid like containing a null reference but invalid in the
sense that a private data member has a value that was not set in the
business logic where it should have been. Using only ctors that init
all the values ensures errors of this sort are caught at compile time.

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.

I don't.

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.

IMHO there is harm. First there is the extra effort of writing the
code.

Eclipse has option to generate getters and setters. And constructors
with (or without) parameters.

And second, if you forget to write one or more of them you dont
get a compile time error, you get a runtime bug.

You do get a compile time error (or warning) if your private (I set
all vars private, unless they HAVE to be NOT private) vars are not
accessible.

And again, having all of the above (setters AND default constructor)
does not mean that YOU have to use them. In your program you can just
ignore them...
.

Relevant Pages

  • Re: XStream versus XMLEncoder
    ... I am currently using XStream. ... as std with java now that can be used to do the same job, XMLEncoder. ... must be a default ctor. ... sense that a private data member has a value that was not set in the ...
    (comp.lang.java.help)
  • Re: XStream versus XMLEncoder
    ... I am currently using XStream. ... object to an XML String and an XML String back to the object. ... as std with java now that can be used to do the same job, XMLEncoder. ... must be a default ctor. ...
    (comp.lang.java.help)
  • XStream versus XMLEncoder
    ... I am currently using XStream. ... object to an XML String and an XML String back to the object. ... as std with java now that can be used to do the same job, XMLEncoder. ... must be a default ctor. ...
    (comp.lang.java.help)