Est-ce faux d'utiliser des méthodes ou des classes obsolètes en Java?

Question

J'utilise eclipse pour développer une application Web. Juste aujourd'hui, j'ai mis à jour ma version struts en modifiant le fichier JAR. Je reçois des avertissements à certains endroits que les méthodes sont obsolètes, mais le code fonctionne correctement.

Je veux savoir certaines choses

1. Est-ce faux d'utiliser des méthodes ou des classes obsolètes en Java?

2. Que se passe-t-il si je ne change pas de méthode et que je lance mon application avec les avertissements que j'ai, cela créera un problème de performance.

Answer 1

1. Est-il de mal à utiliser des méthodes Obsolètes ou les classes en Java?

À partir de la définition de l'obsolète:

Un élément de programme annoté @Deprecated est l'un des programmeurs sont découragés de l'aide, en général parce qu'il est dangereux, ou parce qu'une meilleure alternative.

La méthode est conservé dans l'API, pour assurer la compatibilité descendante pour une période de temps indéfinie, et pourrait à l'avenir être communiqués être supprimé. C'est, non, c'est pas mal, mais il y a une meilleure façon de le faire, ce qui est plus robuste contre les changements de l'API.

2. Que faire si je n'ai pas changer de méthode et d'exécuter mon application avec des avertissements que j'ai, ça va créer un problème de performance.

Probablement pas. Il continuera à fonctionner comme avant l'autodérision. Le contrat de la méthode de l'API ne changera pas. Si certaines données internes des modifications de la structure en faveur d'un nouveau, de meilleure méthode, il pourrait y avoir un impact sur les performances, mais il est très peu probable.

---

Le plus drôle autodérision dans l'API Java, est de l'omi, l' FontMetrics.getMaxDecent. Raison de la dépréciation: erreur d'Orthographe.

Déconseillé. Comme de JDK version 1.1.1, remplacé par getMaxDescent().

Answer 2

Vous pouvez toujours utiliser du code obsolète sans modifier les performances, mais le but de déprécier une méthode / classe est de permettre aux utilisateurs de savoir qu'il existe désormais une meilleure façon de l'utiliser, et que dans une prochaine version, le code obsolète sera probablement supprimé.

Answer 3

La terminologie

De l'autorité de Soleil glossaire:

dépréciation: fait référence à une classe, une interface, constructeur, la méthode ou le champ qui n'est plus recommandé, et peut cesser d'exister dans une version future.

À partir de la comment et quand de déprécier guide:

Vous avez peut-être entendu l'expression, "autodérision", ou l'humour qui minimise l'enceinte de l'importance. Une classe déprécié ou de la méthode est comme ça. Il n'est plus important. Il est donc sans importance, en fait, que vous devez ne plus l'utiliser, car il a été remplacé et ne peut cesser d'exister dans le futur.

L' @Deprecated d'annotation est allé une étape plus loin et avertir d'un danger:

Un élément de programme annoté @Deprecated est l'un des programmeurs sont découragés de l'aide, en général parce qu'il est dangereux, ou parce qu'une meilleure alternative.

Références

• java.sun.com Glossaire
• Guide de langue/Comment et Quand Dénigrent les Api
• Annotation de Type API Obsolètes

---

Bon ou mauvais?

La question de savoir si c'est bon ou mauvais d'utiliser des méthodes obsolètes devront être examinées sur une base individuelle. Voici TOUTES les citations où le mot "obsolète" apparaît dans Efficace Java 2nd Edition:

Article 7: Éviter les finaliseurs: Les seules méthodes qui prétendent garantir la finalisation sont System.runFinalizersOnExit et son jumeau maléfique Runtime.runFinalizersOnExit. Ces méthodes sont fatalement défectueux et ont été remplacés.

Article 66: Synchroniser l'accès et le partage de données mutable: Les bibliothèques fournissent l' Thread.stop méthode, mais cette méthode est obsolète depuis longtemps, car il est intrinsèquement dangereux , son utilisation peut entraîner la corruption des données.

Article 70: Document de sécurité de threads: L' System.runFinalizersOnExit méthode est thread-hostile et a été désapprouvée.

Article 73: Éviter le thread groupes: Ils vous permettent d'appliquer certains Thread des primitives pour un tas de fils à la fois. Plusieurs de ces primitives ont été dépréciés, et le reste sont rarement utilisés. [...] thread groupes sont obsolètes.

Ainsi, au moins avec toutes les méthodes ci-dessus, c'est clairement mal à l'utiliser, au moins selon Josh Bloch.

Avec d'autres méthodes, vous aurez à examiner les questions individuellement, et de comprendre POURQUOI ils ont été déconseillés, mais d'une manière générale, lorsque la décision de rendre caduque est justifiée, il aura tendance à se pencher vers tort que le droit de continuer à les utiliser.

Questions connexes

• La différence entre un Obsolète et l'Héritage de l'API?

Answer 4

En dehors de toutes les excellentes réponses ci-dessus que j’ai trouvé il y a une autre raison pour supprimer déconseillée appels d’API.

Être à recherches sur pourquoi un appel est déconseillé je me surprends souvent apprendre des choses intéressantes sur le Java / l’API/le cadre. Il y a souvent une bonne raison pourquoi une méthode est retirée et comprendre ces raisons mène à des idées plus profondes.

Dans une perspective d’apprentissage/de plus en plus, il est donc aussi un effort vaut la peine

Answer 5

Certes, il ne crée pas une question de rendement-- obsolète signifie, à l’avenir, qu'il est probable que fonction ne sera partie de la bibliothèque plus, donc vous devriez éviter de l’utiliser dans le nouveau code et changer votre ancien code pour cesser de l’utiliser, donc vous ne rencontrez des problèmes un le jour où vous mise à niveau de struts et trouverez cette fonction n’est plus présent