>>>>> "Robert" == Robert Schuster <[EMAIL PROTECTED]> 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
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
