Discussion :

[remi.py]

Bonjour

Une petite question pour comprendre. Lorsque je crée une classe à partir de l'interface Serializable, Eclipse me rajoute un petit warning. Jusqu'à présent, je ne me prenais pas la tête, je rajoutais un :

Code :

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

@SuppressWarnings("serial")

Mais j'ai pu lire que c'était une solution pas glop du tout (le serialVersionUID servant à la déserialisation, il me semble).

Alors, je demande à Eclipse de générer automatiquement ce serialVersionUID. Sur quels éléments se base-t-il pour cela ? Y aurait-il une doc quelque part, présentant l'algorithme ? Je sais juste que ce n'est pas un identifiant aléatoire, je l'ai généré deux fois, avec le même résultat.

D'avance merci

[Baptiste Wicht]

Je ne suis pas tout à fait sûr, mais il me semble qu'il le générait depuis le un hash du code de la classe.

Mais j'ai pu lire que c'était une solution pas glop du tout (le serialVersionUID servant à la déserialisation, il me semble).

Ce n'est effectivement pas l'idéal, mais si tu n'utilises pas la sérialisation sur tes classes, ce n'est pas un problème

En fait cette variable est un identifiant permettant d'identifier (logique ^^) la version de la classe pour savoir si la version sérialisée peut-être désérialisée avec la version actuelle de la classe.

Un problème qui peut néanmoins apparaître si tu ne spécifies par de serialVersionUID, c'est que the classes sérialisables compilées avec Eclipse ne seront pas compatibles avec les mêmes classes compilées avec Javac. Ceci est dû au fait que si tu ne définis pas explicitement cette variable, le compilateur doit en créer une et que le compilateur d'Eclipse ne la génère pas de la même manière que javac.

[adiGuba]

Salut,

Un problème qui peut néanmoins apparaître si tu ne spécifies par de serialVersionUID, c'est que the classes sérialisables compilées avec Eclipse ne seront pas compatibles avec les mêmes classes compilées avec Javac. Ceci est dû au fait que si tu ne définis pas explicitement cette variable, le compilateur doit en créer une et que le compilateur d'Eclipse ne la génère pas de la même manière que javac.

Le problème n'apparait pas entre eclipse et javac mais entre chaque compilation du source.

Comme tu l'a dit la serialization se base sur ce champ pour déterminer s'il s'agit de la même version de la classe, et doit pour déterminer si la sérialization peu se faire. Si ce numéro varie cela provoquera un plantage de la sérialization...

Théoriquement ce numéro devrait changer dès que qu'un champs non-transient est ajouté/modifier/supprimé.

Le problème est que le numéro généré par les compilateurs varie énormément pour la moindre modif : une simple édition du source pourrait engendrer un nouveau numéro et donc casser la sérialization.

Plus d'info : [Java 5.0] serial : "serializable class Main has no definition of serialVersionUID"


Si tu utilises la sérialisation je penses qu'il est plus simple d'utiliser "1" et d'incrémenter à chaque modif

a++

[remi.py]

Ce n'est effectivement pas l'idéal, mais si tu n'utilises pas la sérialisation sur tes classes, ce n'est pas un problème

Je ne l'utilise pas directement, mais j'imagine que les API de persistence de Java, si En fait, dans ce cas, je ne sais pas si le serial id est obligatoire, puisqu'un check est effectué avant le chargement des objets, afin de s'assurer de la compatibilité des entités et de leur image dans la base.

Je vais quand même le laisser, dès fois qu'il y ait un problème avec la vérification et pour éviter ce warning (je n'aime pas avoir des warnings dans mon code).

Merci pour vos réponses