serializing
 

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?

Re: serializing
 

On 10/8/2012 3:08 PM, bob smith wrote:
> 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

Re: serializing
 

bob smith wrote:
> 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.

--
Lew

Re: serializing
 

On 10/8/2012 12:15 PM, Arne Vajhøj wrote:

>
> 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.

Re: serializing
 

On 08/10/2012 23:58, Lew allegedly wrote:
> (Java's inherent serialization handles cycles in the object graph correctly.)

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

[citation needed]

--
DF.

Re: serializing
 

markspace wrote:
> Arne Vajh�j wrote:
>> ObjectOutputStream and ObjectInputStream will get it right.
>
> Thanks for pointing that out. I would have guessed that serialization
> would not get this right.

http://docs.oracle.com/javase/7/docs...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...MLEncoder.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

Re: serializing
 

Daniele Futtorovic wrote:
> Lew allegedly wrote:
>> (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.

--
Lew

Re: serializing
 

On 10/8/2012 5:06 PM, Lew wrote:

>> 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...MLEncoder.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.

Re: serializing
 

On Mon, 8 Oct 2012 12:08:08 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>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 Canadian Mind Products http://mindprod.com
The iPhone 5 is a low end Rolex.

Re: serializing
 

On Mon, 08 Oct 2012 16:16:53 -0700, markspace <-@.> wrote, quoted or
indirectly quoted someone who said :

>
>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.
--
Roedy Green Canadian Mind Products http://mindprod.com
The iPhone 5 is a low end Rolex.