Accueil > Non classé > Serial version UID ?

Serial version UID ?

Capture d’écran 2010-03-18 à 21.46.37

Tout le monde connaît le warning affiché par défaut dans Eclipse quand une classe implémentant Serializable ne déclare pas d’attribut de classe final serialVersionUID de type long. Il y a différents types de réactions :

  • On ne touche à rien, c’est qu’un warning (aka politique de l’autruche).
  • On utilise le quick fix d’eclipse pour supprimer le warning (avec l’annotation @SuppressWarnings("serial")) (autruche aussi).
  • On utilise le quick fix d’eclipse pour générer un attribut serialVersionUID, de valeur 1L ou autre, généré par eclipse, selon les préférences et on n’y touche plus (un huitième de seconde et on y pense plus).

Il y a des gens que les warnings ne dérangent pas, moi je serais plutôt du genre à tout activer et à traquer toutes les petites pastilles jaunes. En général c’est vraiment le signe qu’il y a un truc pas terrible.

En même temps ajouter des numéros dans les classes comme ça sans trop savoir pourquoi…

C’est quoi déjà la sérialisation ?

La sérialisation java est un mécanisme qui permet de stocker des instances de classes dans des fichiers (ou assimilés, comme le réseau ou la session http). On utilise les classes ObjectOutputStream et ObjectInputStream pour, respectivement écrire et lire les données.

Il s’agit d’un mécanisme très ancien, qui paraît formidable de prime abord, quand on écrit son premier démineur en swing : on marque une classe avec l’interface Serializable et l’api java se charge de traduire nos instances dans un format binaire et vice versa.

C’est tout à fait envisageable si l’application qui lit les données et celle qui les écrit sont toutes les deux écrites en java et partagent les classes sérialisables. Ça ne l’est pas si un humain ou une autre application que la vôtre, éventuellement écrite en Purly (nouveau langage à la mode inspiré de Perl et Ruby) peut utiliser vos données.

A quoi sert cet attribut ?

L’attribut serialVersionUID est un genre de numéro de version pour la classe. En effet si votre classe Serializable change dans le temps (ce qui est probable), l’instance stockée dans un fichier n’est peut-être plus compatible avec le programme qui le lit (ou inversement si le programme qui lit est plus ancien).

C’est donc au développeur d’ajouter un attribut serialVersionUID (au départ 1 par exemple) puis de l’incrémenter à chaque ajout ou suppression d’attribut non transient dans la classe. S’il ne le fait pas l’api en génère un, mais le calcul est très sensible.

Ca a pas l’air trop sympa à maintenir vu comme ça. Si on faisait du xml ?

Super, et on l’utilise quand la sérialisation déjà ?

On pourrait se dire « mais on s’en moque, on fait des applications d’entreprise, on ne sérialisera pas nos instances dans des fichiers ».

Oui mais non : la sérialisation est très utilisée en Java EE.

Elle est indispensable si on fait du clustering par exemple. Dès qu’on met des choses en session en fait. Il n’est d’ailleurs pas vraiment rare de voir des frameworks et apis réclamer qu’une classe soit sérialisable (orms, framework mvc, …).

Elle est aussi indispensable si on fait du RMI, par exemple si on utilise des EJB à interface remote.

Quels problèmes peut-on avoir ?

Les problèmes de versions de classes sont relativement peu courant en développement. En général on travaille avec des classes à jour.

On peut avoir des soucis quand on fait une montée de version en production sur un cluster avec les sessions partagées si on change le war/ear noeud par noeud, la nouvelle version ne pourra pas lire les données des autres noeuds et les utilisateurs verront des bugs bizarres.

J’ai déjà vu également des problèmes avec des EJBs : une application déployée sur un JBoss 4.2.2 qui appelait un EJB déployé sur un JBoss 4.2.1, une classe du conteneur ne déclarait pas de serialVersionUID en 4.2.1 mais le faisait en 4.2.2, sans autre changement, ce qui les rendaient incompatibles.

Alors on l’utilise ?

Le mieux est probablement de déclarer l’attribut et d’avoir une politique stable pour le gérer, par exemple comparer les versions de la classe avec la release précédente et incrémenter le numéro s’il y a eu une modification.

Share
Categories: Non classé Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks