De-serializing an object with missing child classes

[raphfrk]

Is this possible?

For example, assuming that I serialized this class

import java.io.*;

public class StorageClass implements Serializable {

private static final long serialVersionUID = 1L;

public Serializable[] stored;

}

I then set the stored array to a set of serializable objects.

At a later time, I want to deserialize the object, but one of the
stored classes is no longer available. Is there a way to deserialize
the object, but have that entry in the array be null?

 

[Robert Klemme]

Is this possible?

For example, assuming that I serialized this class

import java.io.*;

public class StorageClass implements Serializable {

        private static final long serialVersionUID = 1L;

        public Serializable[] stored;

}

I then set the stored array to a set of serializable objects.

At a later time, I want to deserialize the object, but one of the
stored classes is no longer available.  Is there a way to deserialize
the object, but have that entry in the array be null?

Write a custom deserialization. There you can catch exceptions and
deal with the as you see fit. See:

http://download.oracle.com/javase/6/docs/api/java/io/Serializable.html

Kind regards

robert

 

[Roedy Green]

At a later time, I want to deserialize the object, but one of the
stored classes is no longer available. Is there a way to deserialize
the object, but have that entry in the array be null?

The easiest way to do it would be to create a dummy class.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is,
the search for a superior moral justification for selfishness.
~ John Kenneth Galbraith (born: 1908-10-15 died: 2006-04-29 at age: 97)

 

[raphfrk]

http://download.oracle.com/javase/6/docs/api/java/io/Serializable.html

Thanks for the info. Is there a way to create a custom deserializer
that can deserialize already serialized classes?

 

[Roedy Green]

At a later time, I want to deserialize the object, but one of the
stored classes is no longer available. Is there a way to deserialize
the object, but have that entry in the array be null?

Does not RMI automatically ensure everyone has the classes needed?
see http://mindprod.com/jgloss/rmi.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is,
the search for a superior moral justification for selfishness.
~ John Kenneth Galbraith (born: 1908-10-15 died: 2006-04-29 at age: 97)

 

[Arne Vajhøj]

Does not RMI automatically ensure everyone has the classes needed?
see http://mindprod.com/jgloss/rmi.html

No.

And he did not say that he was using RMI either.

Arne

 

[Arne Vajhøj]

Is this possible?

For example, assuming that I serialized this class

import java.io.*;

public class StorageClass implements Serializable {

private static final long serialVersionUID = 1L;

public Serializable[] stored;

}

I then set the stored array to a set of serializable objects.

At a later time, I want to deserialize the object, but one of the
stored classes is no longer available. Is there a way to deserialize
the object, but have that entry in the array be null?

The reason why XML serialization is better than binary serialization
for long time persisting.

Arne

 

[Robert Klemme]

Thanks for the info. Is there a way to create a custom deserializer
that can deserialize already serialized classes?

I am not sure I get exactly what you mean here. Do you want to
resurrect class objects (i.e. the code) from the stream? I don't think
this is possible without complex logic.

Or did you mean you want to write a custom deserializer after instances
have been serialized? It might be possible but you would have to know
how the default serializer writes out data. You may be able to find out
by looking at how an array is serialized by default and then emulating
that (IIRC first the length is written and then individual elements).
You certainly need some experimenting to get this going.

Other than that there are some hints in docs about schema change and how
to deal with that (only it's not called "schema change" but they are
talking about class versions). The java.sun.com had some tutorials but
I don't have any links handy.

Kind regards

robert

 

[Andreas Leitgeb]

I am not sure I get exactly what you mean here.

I understood it such, that he has got some binary blob that was once
generated from serializing an array containing various implementations
of some common interface (e.g. a Serializable[]).

Since then, for some reason, some class files are "irrecoverably lost"
(or maybe just not shipped in some stripped down distribution of his sw),
and the task is *NOT* to recover those lost classes, but to recover just
those other objects whose .class files are still available. The data for
the instances of the lost classes should just be discarded, and a null
written instead of the actual instance.

The question now is, if a custom deserializer could be made data-compatible
with the standard serializer, and specifically skip the attempt to create
those instances of those unknown classes, instead pretending that a null was
originally saved.

Most likely, however, it could be easier to (re)construct a dummy-class
with name and fields and whatnot of the original class. Maybe it can be
cheated in as a substitute of the original class.

PS: the javadocs explicitly advise against using Serialization for
long-term-storage.

 

[raphfrk]

I am not sure I get exactly what you mean here.  Do you want to
resurrect class objects (i.e. the code) from the stream?  I don't think
this is possible without complex logic.

I was thinking that the standard deserializer might be a relatively
low complexity recursive method. It may be possible to copy that and
update it where it checks for a class match.

In the end I just had the custom reader use the defaultReadObject()
method and then read again. If it hit EOF, then I assumed that it was
the old type. Otherwise it read the extra info and updated
accordingly.

When read, it stored the child objects as either a byte array stored
in a dummy object or as the actual object if it could be deserialized.

 

[raphfrk]

Since then, for some reason, some class files are "irrecoverably lost"
(or maybe just not shipped in some stripped down distribution of his sw),
and the task is *NOT* to recover those lost classes, but to recover just
those other objects whose .class files are still available. The data for
the instances of the lost classes should just be discarded, and a null
written instead of the actual instance.

The issue was a plugin system where it would save data associated with
a plugin (or maybe even that the plugin is loaded later).