M
Mark Space
Ken said:I seem to have a misunderstanding of how XMLEncoder works and I'm trying
to resolve it. I thought that XMLEncoder, by default, went through a
Java beans public properties and called get methods to save them, and
then XMLDecoder would call the appropriate setters to set them again, but
It does. You have two problems with your example.
First, you have a getWords, but no setWords. So even given your
understanding it should be obvious that this can't work. XMLDecoder
doesn't' recognize "add" as a substitute for "set".
The second problem is a little more subtle. "getWords" returns a list,
and List is also not a bean. It has a get() method, but that method
needs a parameter, and XMLEncoder can't know what to supply. And
there's still no "set" method for List, so XMLDecoder cant' do a thing
with it.
You'll have to supply getters and setters that return and take
primitives, or arrays of primitives. Or beans, but Collections aren't
beans.
My advice: use the Serialization API. Adding all these methods needed
for XMLEncoder/Decoder will really warp the encapsulation of your
classes. Serialization is much, much easier to work with. And I think
most Collection classes are serializable to boot.
If you don't want to use serialization, you should probably break down
and modify your use of XMLEncoder/Decoder so the API on your classes.
Provide a factor method or something similar to generate your nicely
encapsulated classes from a stream of beans, then use XMLDecoder to get
the beans. You'll also need to make a factory method to make beans from
your main classes, and then use XMLEncoder on that. I think this will
be much cleaner in the long run for you.