Pourquoi Java a-t-il besoin de l'interface Serializable ?

Question

Nous travaillons beaucoup avec la sérialisation et le fait de devoir spécifier la balise Serializable sur chaque objet que nous utilisons est une sorte de fardeau. Surtout lorsqu'il s'agit d'une classe tierce que nous ne pouvons pas vraiment modifier.

La question est la suivante : étant donné que Serializable est une interface vide et que Java fournit une sérialisation robuste une fois que l'on a ajouté implements Serializable - pourquoi n'ont-ils pas fait en sorte que tout soit sérialisable et c'est tout ?

Qu'est-ce que je manque ?

Answer 1

La sérialisation comporte de nombreux pièges. La prise en charge automatique de la sérialisation sous cette forme fait de l'interne de la classe une partie de l'API publique (c'est pourquoi javadoc vous donne l'option formes persistantes de classes ).

Pour une persistance à long terme, la classe doit être capable de décoder cette forme, ce qui limite les changements que vous pouvez apporter à la conception de la classe. Cela rompt l'encapsulation.

La sérialisation peut également entraîner des problèmes de sécurité. En étant capable de sérialiser n'importe quel objet auquel elle fait référence, une classe peut accéder à des données auxquelles elle n'aurait normalement pas accès (en analysant les données d'octets résultantes).

Il y a d'autres problèmes, comme la forme sérialisée des classes internes qui n'est pas bien définie.

Rendre toutes les classes sérialisables exacerberait ces problèmes. Consultez le site Java efficace deuxième édition et en particulier Point 74 : implémenter judicieusement Serializable .

Answer 2

Je pense que les gens de Java et de .Net se sont trompés cette fois-ci, il aurait mieux valu que tout soit sérialisable par défaut et qu'il suffise de marquer les classes qui ne peuvent pas être sérialisées en toute sécurité.

Par exemple, dans Smalltalk (un langage créé dans les années 70), chaque objet est sérialisable par défaut. Je n'ai aucune idée de la raison pour laquelle ce n'est pas le cas en Java, compte tenu du fait que la grande majorité des objets sont sérialisables en toute sécurité et que seuls quelques-uns ne le sont pas.

Marquer un objet comme sérialisable (avec une interface) ne rend pas magiquement cet objet sérialisable, il était sérialisable depuis le début Je ne vois donc pas de raison valable pour que la sérialisation soit telle qu'elle est aujourd'hui.

Je pense qu'il s'agit soit d'une mauvaise décision prise par les concepteurs, soit que la sérialisation a été pensée après coup, soit que la plateforme n'a jamais été prête à effectuer la sérialisation par défaut sur tous les objets de manière sûre et cohérente.

Answer 3

Tout n'est pas véritablement sérialisable. Prenons l'exemple d'une connexion de socket réseau. Vous pouvez sérialiser les données ou l'état de votre objet socket, mais l'essence d'une connexion active serait perdue.

Answer 4

Le rôle principal de Serializable en Java est de rendre, par défaut, tous les autres objets non matérialisables. La sérialisation est un mécanisme très dangereux, surtout dans son implémentation par défaut. C'est pourquoi, comme l'amitié en C++, elle est désactivée par défaut, même s'il en coûte un peu pour rendre les choses sérialisables.

La sérialisation ajoute des contraintes et des problèmes potentiels puisque la compatibilité des structures n'est pas assurée. Il est bon qu'elle soit désactivée par défaut.

Je dois admettre que j'ai vu très peu de classes non triviales où la sérialisation standard fait ce que je veux. Surtout dans le cas de structures de données complexes. Ainsi, l'effort que vous auriez à fournir pour rendre la classe sérialisable correctement éclipse le coût de l'ajout de l'interface.

Answer 5

Pour certaines classes, en particulier celles qui représentent quelque chose de plus physique comme un fichier, une socket, un thread ou une connexion à la base de données, la sérialisation des instances n'a absolument aucun sens. Pour beaucoup d'autres, la sérialisation peut être problématique parce qu'elle détruit les contraintes d'unicité ou vous oblige simplement à traiter des instances de différentes versions d'une classe, ce qui n'est pas forcément souhaitable.

Il aurait sans doute été préférable de tout rendre Serializable par défaut et de rendre les classes non sérialisables par le biais d'un mot-clé ou d'une interface de marquage - mais alors, ceux qui devraient utiliser cette option n'y penseraient probablement pas. En l'état actuel des choses, si vous devez implémenter Serializable, vous en serez informé par une Exception.