Discussion :

[divxdede]

Bonjour,

Voila j'ai une classe A qui est serializable et pour des raisons techniques implemente la méthode "readObject"

j'ai a present une classe B qui hérite de la classe A.
J'ai besoin de spécialiser également la serialisation / deserialisation, donc j'implemente la méthode "readObject"

Le profile de cette méthode m'impose d'être "private" donc ma classe B ne peut pas faire appel a super.readObject(....). Sur ce je me suis dis que la JVM devais faire des appels aux differents readObject de l'arbre d'heritage d'un objet. Est-ce vrai ? et si oui dans quelle ordre ?

En gros est-ce que lors de la de-serialisation il va faire ???

1. B.readObject seulement

2. B.readObject + A.readObject

3. A.readObject + B.readObject

En est-il de même pour writeObject ? l'ordre d'appel est-il inversé ?

Je me pose trop de question pour un Mardi Matin

[sedryk]

Hello

Je ne connais pas parfaitement le fonctionnement interne de la sérialisation mais d'après la Javadoc, les méthodes de lecture et écriture ne doivent être implémentée que dans le cas d'une sérialisation particulière et ne s'occuper que de l'état de l'objet induit par la classe directement et non de l'état des super-classes ou sous-classes.

Ref : Serializable

[divxdede]

Ce qui tends a dire que la JVM s'occupe d'appeler les differents writeObject et readObject des differentes sous-classes.
c'est pour ca qu'il dise que ces méthodes dans une classe particuliere ne doit s'occuper que d'elle même.

Hello

Je ne connais pas parfaitement le fonctionnement interne de la sérialisation mais d'après la Javadoc, les méthodes de lecture et écriture ne doivent être implémentée que dans le cas d'une sérialisation particulière et ne s'occuper que de l'état de l'objet induit par la classe directement et non de l'état des super-classes ou sous-classes.

Ref : Serializable

[bulbo]

Je n'ai rien trouve de precis la dessus.. mais il semblerait que la meme logique que pour les constructeurs soit respectee..

J'ai fais un test et c'est le cas:

D'abord le readObject de la classe mere A puis le readObject de la classe fille B

La recommandation de ne traiter que les champs present dans la classe courante vient surement de la, pour eviter de casser l'init fait par un precedent readObject ..

Bulbo

[divxdede]

Ca concorde bien avec ce que je pensais.
Merci bcp.

J'ai une autre question la dessus, mais je vais ouvrir un autre thread.

Je n'ai rien trouve de precis la dessus.. mais il semblerait que la meme logique que pour les constructeurs soit respectee..

J'ai fais un test et c'est le cas:

D'abord le readObject de la classe mere A puis le readObject de la classe fille B

La recommandation de ne traiter que les champs present dans la classe courante vient surement de la, pour eviter de casser l'init fait par un precedent readObject ..

Bulbo