«

A. Bolmarcich wrote:
> Objects are removed from the stream when they are read. An
> ObjectOutputStream remembers what objects have been written to it. When
> an object is written multiple time to the same ObjectOutputStream, the
> object is written the first time. The other times something else is
> written to the stream; when the reader reads that something else it
> returns a reference to the Object that it has previously read.
>
> Here is a quote from the API documentation at
> http://java.sun.com/j2se/1.4.1/docs/...putStream.html
>
> Multiple references to a single object are encoded using a reference
> sharing mechanism so that graphs of objects can be restored to the
> same shape as when the original was written.
>
> You can invoke the reset() method on the ObjectOutputStream to cause
> it to forget the objects that have been written to it.

What is the point of that? Why would you ever want to write an object
and all its data and then then not be able to do it again? If you
change reference objects but send an object of the same type does it
acutally send the object?

Thanks,

--

Knute Johnson
email s/nospam/knute/
Molon labe...

In article <>, Knute Johnson wrote:
> What is the point of that? Why would you ever want to write an object
> and all its data and then then not be able to do it again? If you
> change reference objects but send an object of the same type does it
> acutally send the object?

The point is that if you write an object of a class like

public class X {
Integer one = new Integer(1);
Object again = one;
}

to an ObjectOutputStream, a reader of the corresponding ObjectInputStream
will read an object where

one == again

is true, just as it was true for the writer of the object.

You can write the same object multiple times. Unless you invoke reset()
on the ObjectOutputStream, the reader will return the same object each
time it is read.

When you invoke writeObject(Object obj) with different obj values,
different objects are written (different objects of the same class are
differnt objects). If the same obj value has been previously
written (without intervening invocation of reset()), the reader will
return the same object.

Now I'm really confused. If you write:

Object x = new Object();
os.writeObject(x);
x = new Object();
os.writeObject(x);

Does it send two Object x? Or just a reference to the previous Object x?

If you write:

Object x = new Object();
os.writeObject(x);
Object y = new Object();
os.writeObject(y);

It is going to write two different Objects to the stream yes?

What about:

Integer x = new Integer(5);
os.writeObject(x);
x = new Integer(10);
os.writeObject(x);

What gets written here? The two objects are not equivalent but have the
same reference.

--

Knute Johnson
email s/nospam/knute/
Molon labe...

In article <>,
Knute Johnson <> wrote:
>
>Integer x = new Integer(5);
>os.writeObject(x);
>x = new Integer(10);
>os.writeObject(x);
>
>What gets written here? The two objects are not equivalent but have the
>same reference.

No, they do not have the same reference. They have the same variable
name, but the outputstream doesn't know their names anyway so it
doesn't care.

When you write
x = new Integer(10);
then you are changing what the variable x is referencing. It used to
reference an Integer object with the value 5, but after that
assignment, it in stead references a newly created Integer object with
the value 10. Incidentally, at this point, your Integer(5) object is
not referenced by anyone anymore and so will get garbage collected
(eventually).

Cheers
Bent D
--
Bent Dalager - - http://www.pvv.org/~bcd
powered by emacs

In article <>, Knute Johnson wrote:
> Now I'm really confused. If you write:

When confused about what a program will do, it is usually helpful to
write small version of the program and run it. What an actual Java
program does is more important than what most programmers think it may
do.

> Object x = new Object();
> os.writeObject(x);
> x = new Object();
> os.writeObject(x);
>
> Does it send two Object x? Or just a reference to the previous Object x?

It does not successfully write any Objects. The writeObject method will
throw a java.io.NotSerializbleException, because Objects are not
serializable.

If you replace new Object() with new of a serializable class, the
corresponding invocation of readObject() will return different objects.
Although the same variable is used as an argument to both invocations of
writeObject(), the value of that argument is different for the two
invocations.

> If you write:
>
> Object x = new Object();
> os.writeObject(x);
> Object y = new Object();
> os.writeObject(y);
>
> It is going to write two different Objects to the stream yes?

Yes, if you replace new Object() with new of a serializable class.

> What about:
>
> Integer x = new Integer(5);
> os.writeObject(x);
> x = new Integer(10);
> os.writeObject(x);
>
> What gets written here? The two objects are not equivalent but have the
> same reference.

The two objects do not have the same refernece. The same variable was
used to hold difference object references at different times. In Java,
arguments are passed by value. The writeObject() method has no way of
knowing that is has been invoked multiple time with the same variable
used as an argument. The value of the variable is pass as the argument,
not a reference to the variable.

On Fri, 27 Jun 2003 20:06:19 -0700, Knute Johnson wrote:

> OK, I understand now but that brings me back to my first question which
> is why would it work this way? Why would you want it to not send the
> serializable object a second time if it was the same serializable object
> with modified fields? If you are going to use some serializable object
> as your data medium, you have to create a new serializable object every
> time you want to send the data over the stream. Is this true if the OOS
> is writing to a file too?

That's 2 questions.

1) Why not re-send an Object?

This achieves 2 things. Firstly, efficiency. Sending the same Object a
second/third/ten-thousandth time involves only sending its ID number
again. Secondly, it prevents infinite recursion in the case of structures
like circularly linked lists, models of railways/roads etc.


2) Why not check if an object has changed fields before re-sending?

I think this is not easily possible with structures of Objects - consider
just a List of Lists of Names. If a name in one of the sub-lists changes,
does that mean the overarching List has changed? The only way to find out
is to follow every reference to every other object, and I think you wind
up with horrible recursion issues again.

Steve