Discussion :

[JuFromParis]

Bonjour,

Je me pose des questions sur une situation car je vais y faire face d'ici peu, je m'explique.

Mon programme réalise des sauvegardes à l'aide de la sérialisation binaire. Mais évidemment lorsque je modifie l'objet concerné, que je l'améliore, l'ouverture des anciennes sauvegardes ne fonctionne plus.

Alors comment géré cela, et faire en sorte que l'utilisateur puisse ouvrir des anciennes versions de fichier, 2 ou 3 versions antérieurs par exemple?

Mais aussi pour gérer le fait que les nouvelles méthodes de l'objet ne fonctionnent pas sur les anciennes versions?

J'ai bien quelques petites idées, mais qui ne me paraissent pas très propre.

Merci d'avance pour votre aide.

[Génoce]

Bonjour,

Il faudrait garder toutes les versions correspondantes de ta classe avec les fichiers binaires.
Donc créer une nouvelle classe à chaque modification, et coder un moyen de reconnaitre la classe correspondante au binaire.

Peut être que ca existe déjà, autant ne pas réinventer la roue, mais je trouve pas.

[JuFromParis]

J'ai trouvé : Le serial version UID est fait pour ca!

[Génoce]

Ah ben nickel,

Tu pourrais nous exposer rapidement comment ca se passe?

[JuFromParis]

Alors, de ce que j'ai compris grâce à la partie versioning de cette page notamment :

http://java.sun.com/developer/techni...serialization/

Il est possible pour les classes implementants serialisable, de créer un attribut static correspondant à un identifiant, c'est le serial version UID :

private static final long serialVersionUID = 4672745540982379891L;


C'est cette identifiant, sérialisé lui aussi, qui va permettre à la JVM de faire la connexion avec la classe correspondante même si celle ci a été modifié.


Si l'on ne fixe pas nous même cette ID, celui ci est créé automatiquement lors de la création de la classe SAUF qu'il est modifié a chaque modification de la classe (ajout/retrait d'attributs, ajout/retrait de méthodes). C'est cette modification qui empêche l'ouverture d'un ancien fichier!


Je n'ai pas encore testé en profondeur, je ne peux donc pas parler du comportement d'un objet face aux méthodes qui n'existait pas lors de sa sérialisation..


Voila, dites moi si j'ai fait des erreurs et surtout n'hésitez pas à rajouter des infos sur le serialversionUID.

[Génoce]

Ok merci des précisions.

Perso, Eclipse me met un warning si je ne génère pas cet UID.
Je sais qu'il servais à la sérialisation, mais je pensais plutôt que c'était pour les objets qui transitaient entre 2 programmes (client / serveur ...)

Du coup, t'es obligé de garder une historique de ta classe en question?

[adiGuba]

Je n'ai pas encore testé en profondeur, je ne peux donc pas parler du comportement d'un objet face aux méthodes qui n'existait pas lors de sa sérialisation..

Les méthodes ne sont pas sérialisées, donc cela n'a aucune influence là dessus.
L'objet que tu recevras correspondra à la version de la classe que tu as chargé en mémoire.



Pour ce qui est des champs, en cas d'absence ils prendront la valeur nulle (même si tu les initialises à la déclaration).

Tu peux pallier à cela en définissant une méthode readResolve() qui vérifierait la valeur des champs ajoutés. Cette méthode est appelée à la fin du processus de sérialisation.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	private Object readResolve() throws ObjectStreamException {
		if (this.monAttrib == null) {
			this.monAttrib = "valeur par defaut";
		}
		return this;
	}

a++