writeObject signature

[Roedy Green]

I just noticed that it is writeObject ( Object o )
rather than writeObject ( Serializable o )

how come?

 

[Skippy]

I just noticed that it is writeObject ( Object o )

rather than writeObject ( Serializable o )

I wondered the same thing, same for readObject.
Seems to me this is a design flaw.

Would have been nice to have this compile-time 'check',
before you launch the app and Exceptions are thrown..

 

[Roedy Green]

I wondered the same thing, same for readObject.
Seems to me this is a design flaw.

My best explanation is that you are going to do a cast check anyway on
reconstitution, and so the cast check to Serializable it would have to
do internally would be wasted.

 

[Roedy Green]

My best explanation is that you are going to do a cast check anyway on
reconstitution, and so the cast check to Serializable it would have to
do internally would be wasted.

Then why not put one on writeObject? To be parallel? To make the
name of the method logical?

 

[Liz]

I just noticed that it is writeObject ( Object o )
rather than writeObject ( Serializable o )

how come?

It's obvious.

 

[Roedy Green]

It's obvious.

That reminds me of a story Professor Melzak told. A math prof was
scribbling out a proof on the board. A student raised his hand, "how
did you get from step A to step B?". "It's trivial the prof replied".
"I don't see it" the student countered.


The prof stopped, and scratched his head. Eventually he left the room
to go think it over, and just before the bell, returned to the class,
and announced triumphantly "It IS trivial".

 

[lyallex]

It's obvious.

Ah, great, can you tell us then.
I have just asked the most experienced java developer/architect I know
and he didn't know the answer ...

Rgds
Lyall



"Process- How will the work and the team be organized?
The team needs to fit the culture in which it will operate,
but you should write software well rather than preserve the
irrationality of an enclosing culture" - Kent Beck

 

[Michael Rauscher]

I just noticed that it is writeObject ( Object o )
rather than writeObject ( Serializable o )

how come?

IMO: I'd say that this is because writeObject writes Objects. In it's
default implementation it writes only objects that have implemented
Serializable. But one may want to provide it's own method to write
Objects, not relying on Serializable.

Bye
Michael

 

[lyallex]

IMO: I'd say that this is because writeObject writes Objects. In it's
default implementation it writes only objects that have implemented
Serializable. But one may want to provide it's own method to write
Objects, not relying on Serializable.

Bye
Michael

I thought this might be the answer until I realised that writeObject
is final and therefore can't be overridden ... there is a method
called writeObjectOverride(Object obj) that the API docs say should be
used to 'override' the default writeObject method (?) but this just
seems to reinforce the original notion that writeObject should take an
argument of type Serializable.

Do you think it could be a 'style' issue.

In fact we have just had a Development consultant here from Sun
Microsystems and even he couldn't come up with good answer.

Rgds
Lyall


"Process- How will the work and the team be organized?
The team needs to fit the culture in which it will operate,
but you should write software well rather than preserve the
irrationality of an enclosing culture" - Kent Beck

 

[Carl Howells]

I just noticed that it is writeObject ( Object o )
rather than writeObject ( Serializable o )

how come?

Because it can also write Externalizable objects. And because the
behavior of Externalizable and Serializable are different enough,
neither one is a superinterface of the other.

Of course, since the behavior of writeObject has to be significantly
different between the two interfaces, this makes one wonder why they
didn't just put two different writeObject methods in, on taking a
Serializable instance, the other taking an Externalizable instance.

I suppose the answer to that is also pretty obvious... If you have an
object that you can send through an ObjectOutputStream, and you don't
know if it's Serializable or Externalizable, someone has to do
instanceof and casts, no matter what. Might as well make them part of
the ObjectOutputStream, instead of forcing the user to write them over
and over again.

 

[Michael Rauscher]

I thought this might be the answer until I realised that writeObject
is final and therefore can't be overridden ... there is a method

In fact :-(

called writeObjectOverride(Object obj) that the API docs say should be
used to 'override' the default writeObject method (?) but this just
seems to reinforce the original notion that writeObject should take an
argument of type Serializable.

Ok, then let's assume that overriding isn't the argument. Even so, I
don't think that writeObject should take a Serializable. I think that
this has something to do with design.

If writeObject would take an argument of type Serializable, this would
only work because AFAIK all objects in (current) Java are instances of
Object.

Serializable doesn't declare any methods. If we would rely only on the
Serializable interface we wouldn't be able to use any method. E.g. there
would be no way to call getClass (because Serializable doesn't define it).

IOW: giving an Object instance to writeObject makes it obvious that
writeObject may send Object-messages to the instance whereas using
Serializable does not.

All IMO of course.

Bye
Michael

 

[Michael Rauscher]

Because it can also write Externalizable objects. And because the
behavior of Externalizable and Serializable are different enough,
neither one is a superinterface of the other.

Externalizable extends Serializable.

Bye
Michael

 

[Carl Howells]

Externalizable extends Serializable.

Mm... That'll teach me to post without actually checking at least once
to see if what I'm thinking has any relationship with reality... :/

 

[Lee Fesperman]

Serializable doesn't declare any methods. If we would rely only on the
Serializable interface we wouldn't be able to use any method. E.g. there
would be no way to call getClass (because Serializable doesn't define it).

Actually, a reference whose type is an interface can utilize the methods declared for
Object. For example,

Serializable thing = new Integer(1);
Class thingClass = thing.getClass();

.... will work just fine.

 

[Roedy Green]

IMO: I'd say that this is because writeObject writes Objects. In it's
default implementation it writes only objects that have implemented
Serializable. But one may want to provide it's own method to write
Objects, not relying on Serializable.

But even if you did use your own technique, would you not still use
the Serialisable marker? You need that in case somebody writes an
object that points to your object.

 

[Roedy Green]

Ok, then let's assume that overriding isn't the argument. Even so, I
don't think that writeObject should take a Serializable. I think that
this has something to do with design.

If writeObject would take an argument of type Serializable, this would
only work because AFAIK all objects in (current) Java are instances of
Object.

that begins to make sense.
However I found I could do this:

Serializable s = ...

fos.writeObject( s );

So serialisables are considered also objects.

Inside writeObject may be another matter.

 

[Liz]

Ah, great, can you tell us then.
I have just asked the most experienced java developer/architect I know
and he didn't know the answer ...

The most experienced java developer/architect I know is my dog.

 

[Michael Rauscher]

Actually, a reference whose type is an interface can utilize the methods declared for
Object. For example,

Serializable thing = new Integer(1);
Class thingClass = thing.getClass();

... will work just fine.

Yes. It works with current versions of the *Java* language because every
object is an instance of Object. Therefore you can cast any object to
type Object and only therefore you can call getClass. Don't think in
Java, draw e.g. an UML static structure diagramm and you'll see, what I
mean.

Bye
Michael

 

[Michael Rauscher]

that begins to make sense.
However I found I could do this:

Serializable s = ...

fos.writeObject( s );

So serialisables are considered also objects.

Due to Javas architecture, anything (AFAIK) is an instance of Object.
Therefore you can cast anything to Object.

Bye
Michael

 

[Michael Rauscher]

Due to Javas architecture, anything (AFAIK) is an instance of Object.
Therefore you can cast anything to Object.

An addition:

For example there's nothing that prevents the Java developers from
creating a new root of the class hierarchy, let's say an AbstractObject
superclass of Object and from introducing a new class tree starting at
AnotherObject which is a subclass of AbstractObject (this is just a
stupid example)

Now, one could easily write a

class X extends AnotherObect implements Serializable {
//...
}

Instances of X aren't instances of Object anymore. Now if writeObject
would rely on the serializable interface, the cast to Object would e.g.
result in a ClassCastException.