Discussion :

[BernardT]

Bonjour tout le monde
Je vous ecrit ce petit message car je suis actuellement, depuis quelque temps meme, intriguer par un petit warning qui me reviens assez souvent.

Code :

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

1
2
 
class WindowGenerator extends JFrame implements ActionListener,WindowListener, java.io.Serializable

La declaration de ce genre de Class me genere un warning du type: "The serializable class WindowGenerator does not declare a static final serialVersionUUID field of type long"
Si quelqu'un pouvai m'eclairer sur ce warning...comment : pourqoui : que faire : et si on le laissait comme ca :

[adiGuba]

Salut,


Je suppose que tu dois utiliser Java 5.0 (ou un EDI compatible). En effet il définit un certain nombre de "nouveaux" warnings dont celui-ci.

Cette question devrait prochainement être intégré à la FAQ :

Ce warning signale qu'une classe qui implémente l'interface java.io.Serilizable n'a pas définit de serialVersionUID. En effet, le serialVersionUID permet d'affecter un numéro de version à la classe. Ce numéro doit normalement être changé lorsqu'un champs non-transiant est ajouté ou supprimé de la classe. Théoriquement, c'est le développeur qui doit créer ce champs. Toutefois, si ce champs est absent, le compilateur générera un numéro automatique.

Le champs serialVersionUID est utilisé lors de la désérialization afin de s'assurer que les versions des classes Java soient concordantes. Si ce n'est pas le cas, une InvalidClassException sera levée.

Or il se trouve que le calcul des serialVersionUID par défaut est extrêmement sensible aux modifications apportées au code source et peut même varier selon les compilateurs. Ce qui a pour inconvénient de provoquer des InvalidClassExceptions inattendus lors de la désérialisation...

Il est ainsi fortement conseillé de gérer le serialVersionUID de toutes classes sérializable, et bien sûr de modifier cette valeur lors d'un changement sur les champs de la classe. Ce warning signalera ainsi toutes classes Serializable sans définition du serialVersionUID explicite :

Main.java:5: warning: [serial] serializable class Main has no definition of serialVersionUID

Pour définir le serialVersionUID, il faut utiliser le code suivant (où 42L est le numéro de la version qui devra être changé à chaque modification sur les champs. La valeur n'a pas d'importance du moment qu'elle change lors d'un changement sur les champs à sérializer) :

Code :

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

private static final long serialVersionUID = 42L;

Donc il te faut définir un serialVersionUID pour faire disparaître le warning...
Toutefois ceci n'est vraiment utile que si tu vas sérializer ta classe...

a++

[BernardT]

Merci

[le y@m's]

salut,
ne risque-t-il pas d'être génant d'utiliser un serialVersionUID déjà utilisé par une autre classe ?

[adiGuba]

salut,
ne risque-t-il pas d'être génant d'utiliser un serialVersionUID déjà utilisé par une autre classe ?

C'est un champs static final... cela ne pose aucun problème...

a++

[le y@m's]

En fait ce que je voudrais savoir c'est:
Je crée une classe MaClasse qui implémente l'interface java.io.Serilizable, définissant le serialVersionUID = 42L.
Je sérialise MaClasse dans un fichier.
Une autre personne crée une autre classe UneAutreClasse qui elle aussi implémente l'interface java.io.Serilizable et définie le serialVersionUID = 42L.
Si cette personne lit mon fichier en désserialisant vers UneAutreClasse, étant donné que les deux classes ont le meme serialVersionUID, que ce passe-t-il ? Est-ce que l'exception InvalidClassException est levée ?

[adiGuba]

En fait, le serialVersionUID est un numéro de version pour la classe, et il n'est utilisé qu'entre classe du même type...
Il n'y a pas de conflit possible avec le serialVersionUID d'une autre classe...


Lors de la sérialisation, le nom complet de la classe et le serialVersionUID est enregistré, suivi par les différents champs de la classe...

Lors de la désérialisation, le serialVersionUID de la classe écrit dans le fichier est comparé à celui de la classe en mémoire de la JVM.
Si il y a une différence alors la compilation échoue...

Si cette personne lit mon fichier en désserialisant vers UneAutreClasse, étant donné que les deux classes ont le meme serialVersionUID, que ce passe-t-il ? Est-ce que l'exception InvalidClassException est levée ?

Non, le type réel de la classe est conservé dans le fichier, ainsi que le serialVersionUID. Lors de la désérialisation, ce serialVersionUID est comparé avec celui de la classe dans le classpath de la JVM.
La méthode readObject() renvoit un objet qui sera bien du type 'MaClasse'. Et donc si tu fais :

Code :

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

UneAutreClasse valeur = (UneAutreClasse) objectInput.readObject()

Tu te retrouvera avec une ClassCastException...


J'espère que c'est clair...

a++

[le y@m's]

J'espère que c'est clair...

nickel

beaucoup