Re: [cp-patches] RFC: XMLEncoder and related infrastructure

[Tom Tromey]

>>>>> "Robert" == Robert Schuster <address@hidden> writes:

Robert> And the bad one: There is an evil problem with object
Robert> references. These happen when you write an object twice or
Robert> more to the stream.

Robert>         o = new Object();
Robert>         encoder.writeObject(o);
Robert>         encoder.writeObject(o);

Robert> But when it happens as part of the encoding process:
Robert>         o = new Object();
Robert>         map = new HashMap();
Robert>         map.put("bla", o);

Robert>         encoder.writeObject(o);
Robert>         encoder.writeObject(map);

Robert> Then the object reference wont show up.

Shouldn't both of these cases serialize basically the same way, using
'idref'?  When I try them with the JDK I get:

    <?xml version="1.0" encoding="UTF-8"?>
    <java version="1.4.2" class="java.beans.XMLDecoder">
     <object id="Inside0" class="Inside"/>
     <object idref="Inside0"/>

and

    <?xml version="1.0" encoding="UTF-8"?>
    <java version="1.4.2" class="java.beans.XMLDecoder">
     <object id="Inside0" class="Inside"/>
     <object class="java.util.HashMap">
      <void method="put">
       <string>hi</string>
       <object idref="Inside0"/>
      </void>
     </object>


Robert> But if you change the code that
Robert> controls this you will run into and endless recursion.

I think the rule is pretty simple -- if you have seen the reference
already, emit a 'idref' reference to the original.

Actually generating this might be a mess though.  The JDK only seems
to emit 'id=' for objects which are actually duplicated in the stream,
which would seem to imply that you have to buffer everything before
doing any writing.  Oh... I see, flush() explicitly resets the state
here.

Tom