XMLEncoder/XMLDecoder and mutable arguments to getters/setters

Discussion in 'Java' started by George Armhold, Sep 1, 2004.

  1. Hi,

    I have a conundrum concerning XMLDecoder and serialization in general.
    I wrote a fairly simple bean that happens to contain a couple of
    ArrayLists internally, and exposes them like this:

    public class MyBean implements Serializable {
    private List foo = new ArrayList();

    public MyBean() {}

    public List getFoo() {
    return foo;

    public void setFoo(final List foo) {
    this.foo = foo;

    I can serialize and de-serialize blissfully using XMLEncoder and
    XMLDecoder. This worked fine as an initial implementation, code was
    put into production, and now we have some business data stored in this

    Some time later I decided that giving access to the underlying List
    data was probably not such a good thing (I actually had a bug that
    modified the lists behind my back.) So I set out to change the
    implementation to make defensive copies of all the data passed in and
    out with the getters and setters. Of course I should have done this
    from the start. So now we have something like this:

    public List getFoo() {
    final List copy = new ArrayList();
    return copy;

    public void setFoo(final List foo) {

    Then to my surprise, the old business data does not get read correctly
    with the defensive copying. I examined the serialized output from the
    old and new versions, and the difference seems to be that with
    defensive copying, the serialized ArrayLists have entries with "id"
    attributes, e.g.:

    <void id="ArrayList0" property="foo">

    The old format, created without defensive copying does not. What's
    going on here? Does XML{De,En}coder somehow "know" when data has been
    copied, and behave differently?

    Thanks for your time.
    George Armhold, Sep 1, 2004
    1. Advertisements

  2. In article <>,
    (George Armhold) wrote:

    > The old format, created without defensive copying does not. What's
    > going on here? Does XML{De,En}coder somehow "know" when data has been
    > copied, and behave differently?

    XMLEncoder uses a "redundancy elimination" algorithm to avoid
    writing default values. To encode a bean X, it creates a new bean Y,
    then compares each property of Y with X. When they differ, it copys
    the value of that property from X to Y, and records what it had to do.
    Then at the end it writes out what it had to do to make Y = X.

    Furthermore, to avoid writing collections (in the generic
    sense, including arrays, lists, and so on), that differ only
    slightly, it checks them element by element and only writes
    the differing values. You can see this by creating a toy bean
    that has an array of A and B by default, make an instance
    that has A and C, and look at what XMLEncoder generates.

    Hence, if you make things non-equal through copying, you can
    trigger odd effects. I'm not sure why you should be getting
    incorrect data stored though.
    Chris Riesbeck, Sep 2, 2004
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Getters and Setters

    , Jun 9, 2006, in forum: Java
    Eddy Young
    Jun 10, 2006
  2. Raaijmakers, Vincent (IndSys,GE Interlogix)

    Newbie in win32com: getters and setters

    Raaijmakers, Vincent (IndSys,GE Interlogix), Oct 23, 2003, in forum: Python
    Raaijmakers, Vincent (IndSys,GE Interlogix)
    Oct 23, 2003
  3. Daniel Fetchinson

    setters and getters in python 2.6 and 3.0

    Daniel Fetchinson, Nov 29, 2007, in forum: Python
    Daniel Fetchinson
    Nov 29, 2007
  4. TechieInsights
    josh logan
    Feb 12, 2009
  5. Lachlan Hunt
    Lachlan Hunt
    Mar 28, 2005

Share This Page