serializing

[bob smith]

Let's say I have this class:

public class Going_to_be_serialized implements Serializable {

public ArrayList<My_Rectangle> rectangles;

public My_Rectangle cur_rect;



So, there are four rectangles in "rectangles".

The "catch" is that cur_rect points to the first rectangle in "rectangles".

So, will there be five rectangles stored when I serialize this? Or will
cur_rect magically point to the first rectangle?

 

[Arne Vajhøj]

Let's say I have this class:

public class Going_to_be_serialized implements Serializable {

public ArrayList<My_Rectangle> rectangles;

public My_Rectangle cur_rect;

So, there are four rectangles in "rectangles".

The "catch" is that cur_rect points to the first rectangle in "rectangles".

So, will there be five rectangles stored when I serialize this? Or will
cur_rect magically point to the first rectangle?

ObjectOutputStream and ObjectInputStream will get it right.

I would have made cur_rect an index.

And obviously private fields and public getters/settters.

Arne

 

[Lew]

Let's say I have this class:

public class Going_to_be_serialized implements Serializable {
public ArrayList<My_Rectangle> rectangles;
public My_Rectangle cur_rect;

So, there are four rectangles in "rectangles".

The "catch" is that cur_rect points to the first rectangle in "rectangles".

So, will there be five rectangles stored when I serialize this? Or will
cur_rect magically point to the first rectangle?

Java's inherent serialization handles cycles in the object graph correctly. It's not very
space-efficient at doing so.

GIYF.

 

[markspace]

ObjectOutputStream and ObjectInputStream will get it right.

Thanks for pointing that out. I would have guessed that serialization
would not get this right.

Does anyone know what XmlEncoder/Decoder do off hand? I would think the
problem is even harder here, but maybe there's a trick they use to
prevent errors there too.

 

[Daniele Futtorovic]

(Java's inherent serialization handles cycles in the object graph correctly.)

It's not very space-efficient at doing so.

[citation needed]

 

[Lew]

Thanks for pointing that out. I would have guessed that serialization
would not get this right.

http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serialTOC.html

Linked from the java.io API docs.

"The writeObject method (see Section 2.3, "The writeObject Method") serializes the specified object and
traverses its references to other objects in the object graph recursively to create a complete serialized
representation of the graph. Within a stream, the first reference to any object results in the object being
serialized or externalized and the assignment of a handle for that object. Subsequent references to that
object are encoded as the handle. Using object handles preserves sharing and circular references that
occur naturally in object graphs. Subsequent references to an object use only the handle allowing a very
compact representation."

No need for guesswork.

Does anyone know what XmlEncoder/Decoder do off hand? I would think the
problem is even harder here, but maybe there's a trick they use to
prevent errors there too.

The API docs do.

http://docs.oracle.com/javase/7/docs/api/java/beans/XMLEncoder.html
“XML's standard "id" and "idref" attributes are used to make references to previous expressions -
so as to deal with circularities in the object graph.”

 

[Lew]

(Java's inherent serialization handles cycles in the object graph correctly.)
It's not very space-efficient at doing so.

[citation needed]

Further research indicates that I'm wrong here.

 

[markspace]

The API docs do.

http://docs.oracle.com/javase/7/docs/api/java/beans/XMLEncoder.html
“XML's standard "id" and "idref" attributes are used to make references to previous expressions -
so as to deal with circularities in the object graph.”

Nice! Thanks for reading the docs for me (I was being very lazy, I
admit). Good to know too that they found a way deal with circular
references there too.

 

[Roedy Green]

Let's say I have this class:

It all works no matter what a tangled mess of interconnections you
have. The worst that can happen is you end up serialising a lot of
dependent objects you forgot about.

The serialisation process keeps track of which objects it has already
written to the stream. If it encounters a link to an already written
object, it just outputs a reference to it (I have not looked recently,
but it is probably just a serial number). If it finds a new object,
it serialises it recursively, then outputs the link to it.

I have forgotten if it keeps each object contiguous, by delaying write
or if it embeds.

 

[Roedy Green]

Does anyone know what XmlEncoder/Decoder do off hand? I would think the
problem is even harder here, but maybe there's a trick they use to
prevent errors there too.

It is basically the same thing, except the stream is chars XML instead
of binary. I would expect it to be considerably less compact.

 

[Arne Vajhøj]

Thanks for pointing that out. I would have guessed that serialization
would not get this right.

Does anyone know what XmlEncoder/Decoder do off hand?

It gets it right also.

For the same reason: when you serialize something and then
deserialize you expect to get the same as before.

Let us say that you have a class that contains two
HashMap and basically maps bidirectional between
two sets of data. If serialization + deserialization
resulted in having all data objects being duplicated, then
things could real messy.

Arne

 

[Arne Vajhøj]

It is basically the same thing, except the stream is chars XML instead
of binary. I would expect it to be considerably less compact.

Real serialization and XmlEncode/XmlDecode is very different
in what they do and how they do it.

Arne