Re: XStream versus XMLEncoder
- From: GArlington <garlington@xxxxxxxxxxxxx>
- Date: Wed, 5 Dec 2007 03:45:30 -0800 (PST)
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 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.
.
- Follow-Ups:
- Re: XStream versus XMLEncoder
- From: apm35
- Re: XStream versus XMLEncoder
- From: Lew
- Re: XStream versus XMLEncoder
- References:
- XStream versus XMLEncoder
- From: apm35
- XStream versus XMLEncoder
- Prev by Date: Re: Math/Programming Algorithm Help
- Next by Date: Re: help with return statement
- Previous by thread: XStream versus XMLEncoder
- Next by thread: Re: XStream versus XMLEncoder
- Index(es):
Relevant Pages
|
