Nous avions laissé notre héros au moment où il se rendait compte que cette merveilleuse API, la sérialization Java, pouvait tout faire elle-même, sans qu’il ait à se préoccuper d’autre chose que d’ouvrir un fichier ou une socket. En grattant un peu la surface, il s’est rendu compte qu’il pouvait personnaliser quelques aspects.
Mais il n’est pas au bout de ses découvertes, et en continuant son exploration, il va se rendre compte qu’il peut aller bien plus loin encore !
La sérialization Java fait partie de ces mécanismes présents dès les premières versions du langage. Elle n’a subi qu’une seule modification majeure, depuis longtemps assumée par tout le monde. Elle fait également partie de ces mécanismes que l’on utilise sans même y penser, qui ont tendance à « marcher tous seuls », sans que l’on ait à s’en préoccuper. Il y a bien ce warning qu’Eclipse ne manque pas de nous coller lorsque l’on crée une classe sérializable sans déclarer de champ serialVersionUID. Mais finalement, il suffit de le créer et de lui coller une valeur au hasard pour que notre IDE préféré (quoique…) soit satisfait. Même plus besoin de connaître exactement le rôle de ce champ… Et quand bien même on ne le déclare pas, Eclipse continue de couiner, mais sans conséquence apparente sur le fonctionnement de notre application.
La sérialization Java permet de résoudre la plupart des problème qu’elle traite, de façon transparente, et sans avoir à connaître son fonctionnement interne. Finalement, n’est-ce pas ça la définition d’une API efficace ?
Le petit voyage auquel je t’invite à présent, précieux lecteur, va précisément nous mener dans les bas-fonds de cette API, de son fonctionnement interne, et des possibilités qu’elle offre, quasiment jamais utilisées. Un voyage inutile ? Peut-être, mais pour le savoir, il faut l’avoir fait !