serialisation panic

[Roedy Green]

But this has nothing to do with deserialization, of course.

It would if the object coming in the wire has never been seen before.
We have the class files on tap, but they have not yet been loaded.

 

[EJP]

Are there circumstances where fields of non-serialisable superclasses
don't get saved/restored?

There are no circumstances where they *do* get saved/restored. They're
not serializable, so they don't get serialized or deserialized. They get
whatever the default contructor and/or the variable initializers put there.

 

[Lew]

There are no circumstances where they *do* get saved/restored. They're
not serializable, so they don't get serialized or deserialized. They get
whatever the default contructor and/or the variable initializers put there.

More precisely, what the no-arg constructor put there.

 

[Lew]

It would if the object coming in the wire has never been seen before.

You mean if its class has never been seen before.

We have the class files on tap, but they have not yet been loaded.

OK, not "nothing" to do with serialization, but static fields are not
deserialized, they're initialized when the class is loaded, whether because of
serialization or for any other reason. In that sense the initialization is
not dependent on (de)serialization, which is what I was trying to convey.

The matter of static initialization is orthogonal to serialization, I should
have said. Since we are picking nits.

 

[Roedy Green]

OK, not "nothing" to do with serialization, but static fields are not
deserialized, they're initialized when the class is loaded, whether because of
serialization or for any other reason. In that sense the initialization is
not dependent on (de)serialization, which is what I was trying to convey.

Normally class loading happens as a side effect of running constructor
or a method. With serialisation reconstitution, you don't run any
methods. So some special mechanism is necessary to get the class
loaded.

It might call <clinit> or it might use reflection to call some
innocuous method of Object.

 

[Lew]

Normally class loading happens as a side effect of running constructor
or a method. With serialisation reconstitution, you don't run any
methods. So some special mechanism is necessary to get the class
loaded.

It might call <clinit> or it might use reflection to call some
innocuous method of Object.

Regardless of why the class loads, initialization of the static members is a
function of class loading, not deserialization.

 

[Mike Schilling]

Normally class loading happens as a side effect of running
constructor
or a method. With serialisation reconstitution, you don't run any
methods.

Or there's some hidden method, called during deserialization, which
gives you an uninitialized object given the class object,

Object getUninitializedObject(Class clazz)

The class will be initialized when "clazz" is created, e.g. via
Class.forName().. No special mechanism required.

 

[Roedy Green]

Regardless of why the class loads, initialization of the static members is a
function of class loading, not deserialization.

But then what causes class loading? Perhaps it does a classForName .
Does that actually force the load?

 

[Thomas Fritsch]

But then what causes class loading? Perhaps it does a classForName .
Does that actually force the load?

I'd say yes.

During deserialization the ObjectInputStream somehow converts from class
names (embedded in the byte-stream) to Class objects, AFAIK in method
ObjectInputStream.resolveClass. In this method there is (as you already
guessed) indeed a call to Class.forName

 

[EJP]

More precisely, what the no-arg constructor put there.

More precisely still, the state is the same as if you had invoked the
no-arg constructor, consisting of what super(), the variable
initializers, the instance initialization block {}, and the code in the
no-arg constructor put there.

 

[Lew]

More precisely still, the state is the same as if you had invoked the
no-arg constructor, consisting of what super(), the variable
initializers, the instance initialization block {}, and the code in the
no-arg constructor put there.

Somewhat redundant, actually. All that happens if you invoke the no-arg
constructor, so saying "what the no-arg constructor put there" subsumes the rest.

 

[EJP]

Somewhat redundant, actually. All that happens if you invoke the no-arg
constructor, so saying "what the no-arg constructor put there" subsumes
the rest.

Agreed. I was just making the pedantic point that what the no-args
constructor does isn't limited to the code that appears inside it ...

 

[Rob]

I had a good dream about a woman last night. Try it some time.

Rob
http://cbmc64.blogspot.com

 

[Lew]

I had a good dream about a woman last night. Try it some time [sic].

Rob
http://cbmc64.blogspasm.sputum

PLONK!