Extrait du glossaire officiel de Sun :
dépréciation : Fait référence à une classe, une interface, un constructeur, une méthode ou un champ qui n'est plus recommandé, et qui peut cesser d'exister dans une version future.
Du guide "Comment et quand déprécier" :
Vous avez peut-être déjà entendu l'expression "humour autodévalorisant", ou humour qui minimise l'importance de la personne qui parle. Une classe ou une méthode dépréciée est comme cela. Elle n'est plus importante. Elle est si peu importante, en fait, que vous ne devriez plus l'utiliser, car elle a été remplacée et pourrait cesser d'exister à l'avenir.
En @Deprecated
L'annotation allait un peu plus loin et avertissait du danger :
Un élément de programme annoté @Deprecated
est l'un de ceux que les programmeurs sont découragés d'utiliser, généralement parce qu'il est dangereux ou parce qu'il existe une meilleure alternative.
Références
Notez que le glossaire officiel ne définit pas ce que signifie "héritage". Selon toute vraisemblance, il s'agit d'un terme utilisé par Josh Bloch sans définition exacte. L'implication, cependant, est toujours qu'une classe héritée ne devrait jamais être utilisée dans un nouveau code, et qu'une meilleure substitution existe.
Peut-être qu'un ancien code utilisant des classes héritées mais non dépréciées ne nécessite aucune action, puisque pour le moment du moins, elles ne risquent pas de cesser d'exister dans une future version.
En revanche, la dépréciation avertit explicitement qu'ils peuvent cesser d'exister, et qu'il faut donc prendre des mesures pour migrer vers leur remplacement.
Citations de Effective Java 2e édition
Pour comparer la façon dont ces termes sont utilisés dans le contexte, voici des citations du livre où le mot "déprécié" apparaît :
Point 7 : Évitez les finalistes : Les seules méthodes qui prétendent garantir la finalisation sont System.runFinalizersOnExit
et son jumeau diabolique Runtime.runFinalizersOnExit
. Ces méthodes sont fatalement défectueuses et ont été dépréciées.
Item 66 : Synchroniser l'accès aux données mutables partagées : Les bibliothèques fournissent les Thread.stop
mais cette méthode a été dépréciée il y a longtemps car elle est intrinsèquement non sécurisé -- son utilisation peut entraîner une corruption des données.
Point 70 : Sécurité du filetage des documents : Le site System.runFinalizersOnExit
est hostile aux threads et a été dépréciée.
Point 73 : éviter les groupes de fils : Ils vous permettent d'appliquer certaines Thread
à un grand nombre de threads en même temps. Plusieurs de ces primitives ont été dépréciées, et les autres sont peu utilisées. [...] les groupes de threads sont obsolètes.
En revanche, ce sont les citations où le mot "héritage" apparaît :
Point 23 : ne pas utiliser de types bruts dans le nouveau code : Ils sont fournis pour la compatibilité et l'interopérabilité avec le code hérité qui précède l'introduction des génériques.
Point 25 : Préférer les listes aux tableaux : L'effacement est ce qui permet aux types génériques d'interopérer librement avec le code hérité qui n'utilise pas les génériques.
Point 29 : envisager des conteneurs hétérogènes sûrs sur le plan du type : Ces wrappers sont utiles pour retrouver qui ajoute un élément mal typé à une collection dans une application qui mélange du code générique et du code hérité.
Point 54 : utiliser judicieusement les méthodes indigènes : Ils donnent accès à des bibliothèques de code patrimonial, qui pourraient à leur tour donner accès à des données patrimoniales. [...] Il est également légitime d'utiliser des méthodes natives pour accéder au code hérité. [...] Si vous devez utiliser des méthodes natives pour accéder à des ressources de bas niveau ou à des bibliothèques héritées, utilisez le moins de code natif possible et testez-le de manière approfondie.
Point 69 : préférer que les services publics de concurrence attendent et notifient. : Bien qu'il faille toujours utiliser les utilitaires de concurrence de préférence au wait
y notify
vous pourriez avoir à maintenir un code hérité qui utilise wait
y notify
.
Ces citations n'ont pas été soigneusement sélectionnées : ce sont TOUS des cas où le mot "déprécié" y "héritage" apparaissent dans le livre. Le message de Bloch est clair ici :
- Les méthodes obsolètes, par exemple
Thread.stop
sont dangereux, et devraient jamais être utilisé.
- D'autre part, par exemple
wait/notify
peuvent rester dans l'ancien code, mais ne doivent pas être utilisés dans le nouveau code.
Mon opinion subjective
Selon moi, déprécier quelque chose, c'est admettre que c'est une erreur et que cela n'a jamais été bon. D'autre part, classer quelque chose comme un héritage, c'est admettre qu'il était assez bon dans le passé, mais qu'il a atteint son but et n'est plus assez bon pour le présent et le futur.