Re: serialisation panic

From:

"Mike Schilling" <mscottschilling@hotmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 11 Jan 2008 11:23:32 -0800

Message-ID:

<RmPhj.4027$El5.1740@newssvr22.news.prodigy.net>

Thomas Fritsch wrote:

Zig wrote:

Thomas Fritsch wrote:

Roedy Green schrieb:

1. If a class does not have a no-arg constructor, how is it
possible for serialisation to reconstitute the object?

It is not. See the API doc of Serializable:
<quote>
During deserialization, the fields of non-serializable classes
will
be initialized using the public or protected no-arg constructor
of
the class. A no-arg constructor must be accessible to the
subclass
that is serializable.
</quote>

True for a class that is non-serializable. Though I think Roedy's
question was about how Serialization does it under the hood for
serializable classes?

Oops, you're right. I confused non-serializable with serializable.

For those, I assume Serialization is using the JNI function
AllocObject: <quote>
jobject AllocObject(JNIEnv *env, jclass clazz);

Allocates a new Java object without invoking any of the
constructors
for the object. Returns a reference to the object.
</quote>

Sounds very reasonable to me. Actually for classes like Boolean
(implements Serializable, but has no no-arg-constructor) I see no
other way for (de)serialization than JNI-AllocObject.

Can I quibble here? (De)Serialization is one of the facilities in
Java that require native methods. (Another is synchronization via
wait()/notify()). That is, a JVM implementation must implement a way
of creating the object that doesn't involve calling a constructor
immediately thereafter, and make this mechanism available to
readObject(). It's possible that this is the JNI function
AllocObject. It's also possible that the two both call some
lower-level function. A third possibility is that the implementations
are wholly unrelated.