Persistance

 

La persistance des objets a été mise en place dans la version 1.1 de Java à l'aide du mécanisme de linéarisation^5.24. En Java 1.1 un objet, sous certaines conditions, peut être sauvegardé dans un fichier et, plus tard, reconstitué entièrement après le chargement adéquat du même fichier.

En effet les conditions et automatismes de ce mécanisme sont les suivants :

• Les objets doivent se déclarer comme persistants (i.e. leur classe doit implémenter l'interface ``serializable'').
• La plupart des objets de Java (tels les tableaux, les vecteurs, etc.) sont déjà persistants (i.e. ils peuvent être linéarisés).
• La linéarisation d'un objet entraîne la linéarisation de tous les objets qu'il contient (sauf ceux qui sont expressément déclarés comme non persistants à l'aide du mot réservé en Java transient) peu importe leur type, pour peu qu'ils soient eux aussi linéarisables. Ainsi, il est possible de sauver et de recharger tout un graphe d'objets en linéarisant un nud racine du graphe.
• Au cas où il est nécessaire d'effectuer des opérations supplémentaires avant la sauvegarde et après le chargement d'un objet, Java 1.1 permet de modifier le comportement standard du mécanisme de linéarisation.

  Ceci peut s'avérer utile pour résoudre des incompatibilités quand une future version étendue du modèle essaiera de charger un fichier généré par une version antérieure. En ajoutant un traitement supplémentaire après la lecture du fichier et la création de l'objet, on peut, par exemple, initialiser une variable qui n'existait pas dans le modèle antérieur. Nous considérons le cas de l'évolution du modèle (passage d'une version à une autre) dans la section 5.5.3.

De cette manière il devient possible de remplir les objectifs posés en 5.3.1 :

• Nous ne devons pas nous occuper manuellement de la sauvegarde des données : Java s'en charge automatiquement.
• Ce dernier nous libère des considérations délicates sur la manière dont les données seront textualisées et écrites dans des fichiers
• Le fichier généré ne peut être lu que par le modèle lui-même^5.25, donc les modifications en dehors d'une application (e.g. en éditant le fichier texte à la main) ne sont plus possibles, ce qui évite d'éventuels problèmes de données non pertinentes.
• Il devient possible d'effectuer des copies du graphe d'objets (i.e. de l'information sémique à sauvegarder) à différents moments d'une application. Celle-ci peut ensuite réutiliser de manière sélective l'une ou l'autre des sauvegardes (e.g. pour un partage d'informations sélectif, ou pour mettre en uvre une simple fonctionnalité annuler). Le chargement sélectif reste bien sûr transparent pour l'application, les objets périmés sont nettoyés par le système^5.26.
• Une sauvegarde du graphe d'objets par une application, peut aussi bien être utilisée par d'autres applications qui peuvent ainsi privilégier un partage rapide des données sémantiques.

Le modèle présenté plus haut contient une classe (cf. la classe DB_AccesExt) dont le rôle est la sauvegarde et le chargement de l'ensemble du modèle. Une application peut l'utiliser indirectement, en appelant la méthode correspondante de la classe interface DB_InterfaceDB pour charger les informations sémiques déjà sauvegardées dans un fichier ou, symétriquement, pour sauvegarder ses propres modifications en vue de les réutiliser plus tard.