Pourquoi java.io.Serializable n’est-il pas obsolète en Java 5?

Avant Java 5, il n’y avait pas d’annotations. Par conséquent, vous ne pouvez pas append de métadonnées à une classe.

Pour marquer une classe comme sérialisable, vous deviez implémenter l’interface Serializable (c’est-à-dire un marqueur) et utiliser d’autres mots-clés transient pour marquer un champ comme non sérialisable si nécessaire, comme par exemple:

 public class MyClass implements Serializable { ... private transient Bla field; ... }

Maintenant, vous pouvez théoriquement utiliser des annotations (c’est une utilisation parfaite pour elles) et avoir:

 @Serializable public class MyClass { ... @Transient private Bla field; ... }

Mais l’interface et le mot clé n’étaient pas obsolètes et aucune annotation n’a été ajoutée à Java 5 pour les remplacer.

Quelles sont les considérations pour que cette décision conserve l’interface et le mot clé?

Bien sûr, il y a un problème de compatibilité avec le code antérieur à Java 5, mais il se termine à un moment donné (par exemple, en ce qui concerne les nouvelles fonctionnalités des génériques, le JLS précise qu’il est possible que les futures versions du langage de programmation Java interdisent l’utilisation. des types bruts ). Alors, pourquoi ne pas préparer la voie aux annotations sérialisées également?

Des pensées? (bien que je préfère des références concrètes: D que je n’ai pas pu trouver)

L’interface est là, donc les méthodes peuvent être définies pour accepter les objects de type Serializable:

 public void registerObject(Serializable obj);

Bien sûr, il y a le problème de la compatibilité avec le code antérieur à Java 5 …

Oui. C’est la racine du problème.

S’ils @deprecated l’interface Serializable dans (par exemple) Java 5, beaucoup d’anciens codes antérieurs à Java 5 donneraient des avertissements (ou des erreurs en fonction des commutateurs du compilateur).
Il n’ya rien de mal à utiliser Serializable et il est agaçant de “forcer” les gens à le remplacer. (Les gens ont mieux à faire …)
Lorsque les utilisateurs ont “corrigé” cela dans leur code, il ne comstackra plus à l’aide d’un compilateur antérieur à Java 5, ni ne s’exécutera sur une JVM antérieure à Java 5.
Il est déconseillé de faire des choses qui font du compilateur systématiquement un “cri de loup”.

… mais à un moment donné, ça finira.

En réalité, la probabilité que cela se produise est faible (OMI). Autant que je sache, Sun / Oracle n’a jamais supprimé une fonctionnalité obsolète. Pas même les plus dangereux comme Thread.stop() et ses amis.

En note de bas de page, les développeurs de Go adoptent une approche différente de ce problème. Quand ils veulent changer une langue ou une fonctionnalité de bibliothèque, ils le font simplement. Ils fournissent un convertisseur qui réécrira automatiquement votre code selon les besoins.

Serializable et transient sont en effet deux choses qui auraient pu être remplacées par des annotations.

Ils ne sont pas obsolètes probablement parce que de nombreux programmes utilisent Serializable et que des millions de développeurs auraient été agacés si le compilateur commençait à générer des milliers d’avertissements de dépréciation.

L’API Java standard contient de nombreuses autres choses qui auraient pu être obsolètes il y a bien longtemps, par exemple les anciennes classes de collection Vector et Hashtable (et je suis sûr que vous pouvez facilement trouver beaucoup plus d’éléments). Et il y a d’autres choses qui auraient pu être implémentées en utilisant des annotations (par exemple, le mot clé volatile , ssortingctfp et synchronized ).

La dépréciation est pour les choses qui sont activement nuisibles. Ce que vous proposez, c’est d’obliger les auteurs de huit années de code Java existant (à l’époque) à le réécrire, sans aucun avantage, simplement pour fermer les avertissements du compilateur déprécation, afin de revenir au code entièrement correct qu’ils avaient avec Java 1.4. . Cela ne serait pas utile.