¿Es incorrecto usar métodos o clases obsoletos en Java?

Estoy usando eclipse para desarrollar una aplicación web. Justo hoy he actualizado mi versión de struts cambiando el archivo JAR. Recibo advertencias en algunos lugares de que los métodos están en desuso, pero el código funciona bien.

Quiero saber algunas cosas

1. ¿Es incorrecto usar métodos o clases obsoletos en Java?

2. ¿Qué sucede si no cambio ningún método y ejecuto mi aplicación con las advertencias que tengo? ¿Creará algún problema de rendimiento?

1. ¿Es incorrecto usar métodos o clases obsoletos en Java?

De la definición de obsoleto :

Un elemento de programa anotado @Deprecated es uno que se desaconseja que los programadores usen, generalmente porque es peligroso o porque existe una mejor alternativa.

El método se mantiene en la API por compatibilidad con versiones anteriores durante un período de tiempo no especificado, y puede que en futuras versiones se elimine. Es decir, no, no está mal , pero hay una mejor manera de hacerlo, que es más robusta frente a los cambios de API.

2. ¿Qué sucede si no cambio ningún método y ejecuto mi aplicación con las advertencias que tengo? ¿Creará algún problema de rendimiento?

Lo más probable es que no. Continuará funcionando como antes de la desaprobación. El contrato del método API no cambiará. Si alguna estructura interna de datos cambia a favor de un método nuevo y mejor, podría haber un impacto en el rendimiento, pero es bastante improbable.

La desaprobación más divertida en la API de Java, es imo, elFontMetrics.getMaxDecent . Motivo de desaprobación: error de ortografía.

Obsoleto. A partir de la versión 1.1.1 de JDK, reemplazada por getMaxDescent ().

Todavía puede usar código en desuso sin que se cambie el rendimiento, pero el objetivo principal de despreciar un método / clase es informar a los usuarios que ahora hay una mejor manera de usarlo, y que en una versión futura es probable que se elimine el código en desuso.

Terminología

Del glosario oficial de Sun:

desaprobación : se refiere a una clase, interfaz, constructor, método o campo que ya no se recomienda y que puede dejar de existir en una versión futura.

De la guía de cómo y cuándo desaprobar:

Es posible que haya escuchado el término "humor autocrítico" o humor que minimiza la importancia del hablante. Una clase o método obsoleto es así. Ya no es importante. Es tan poco importante, de hecho, que ya no debería usarlo, ya que ha sido reemplazado y puede dejar de existir en el futuro.

La @Deprecatedanotación fue un paso más allá y advirtió sobre el peligro:

Un elemento de programa anotado @Deprecatedes uno que se desalienta a los programadores de usar, generalmente porque es peligroso o porque existe una mejor alternativa.

Referencias

• java.sun.com Glosario
• Guía de idiomas / Cómo y cuándo desaprobar las API
• Tipo de anotación API obsoleta

¿Bien o mal?

La cuestión de si es correcto o incorrecto utilizar métodos obsoletos tendrá que examinarse de forma individual. Aquí están TODAS las citas donde aparece la palabra "en desuso" en Effective Java 2nd Edition :

Punto 7: Evitar finalizadores : los únicos métodos que afirman garantizar la finalización son System.runFinalizersOnExity su gemelo malvado Runtime.runFinalizersOnExit. Estos métodos tienen fallas fatales y han quedado en desuso.

Elemento 66: Sincronice el acceso a datos mutables compartidos : las bibliotecas proporcionan el Thread.stopmétodo, pero este método fue desaprobado hace mucho tiempo porque es inherentemente inseguro ; su uso puede provocar la corrupción de los datos.

Artículo 70: Seguridad del hilo del documento : ElSystem.runFinalizersOnExit método es hostil para subprocesos y ha quedado en desuso.

Elemento 73: Evite grupos de hilos : le permiten aplicar ciertas Threadprimitivas a un montón de hilos a la vez. Varios de estos primitivos han quedado en desuso, y el resto se usa con poca frecuencia. [...] los grupos de hilos son obsoletos.

Entonces, al menos con todos los métodos anteriores, es claramente incorrecto usarlos, al menos según Josh Bloch.

Con otros métodos, tendrías que considerar los problemas individualmente y entender POR QUÉ fueron desaprobados, pero en términos generales, cuando la decisión de desaprobar está justificada, tenderá a inclinarse hacia lo incorrecto que lo correcto para continuar usándolos.

Preguntas relacionadas

• ¿Diferencia entre una API obsoleta y una heredada?

Aparte de todas las excelentes respuestas anteriores, descubrí que hay otra razón para eliminar las llamadas API obsoletas.

Investigue por qué una llamada está en desuso A menudo me encuentro aprendiendo cosas interesantes sobre Java / API / Framework. A menudo hay una buena razón por la cual un método está en desuso y entender estas razones conduce a una comprensión más profunda.

Entonces, desde una perspectiva de aprendizaje / crecimiento, también es un esfuerzo que vale la pena

Ciertamente no crea un problema de rendimiento: en desuso significa que en el futuro es probable que la función ya no sea parte de la biblioteca, por lo que debe evitar usarla en un código nuevo y cambiar su código anterior para dejar de usarla, por lo que no tienes problemas un día cuando actualizas struts y descubres que esa función ya no está presente

No está mal, simplemente no se recomienda. Generalmente significa que en este punto hay una mejor manera de hacer las cosas y que harías bien si usas la nueva forma mejorada. Algunas cosas obsoletas son realmente peligrosas y deben evitarse por completo. La nueva forma puede producir un mejor rendimiento que la obsoleta, pero no siempre es así.

Es posible que haya escuchado el término "humor autocrítico". Ese es el humor que minimiza tu importancia. Una clase o método obsoleto es así. Ya no es importante. Es tan poco importante, de hecho, que ya no debería usarse, ya que probablemente dejará de existir en el futuro.

Intenta evitarlo

1. En general, no, no es absolutamente incorrecto usar deprecatedmétodos siempre que tenga un buen plan de contingencia para evitar problemas si esos métodos desaparecen de la biblioteca que está utilizando. Con la API de Java en sí, esto nunca sucede, pero con casi cualquier otra cosa significa que se eliminará. Si planea específicamente no actualizar ( aunque lo más probable es que a la larga ) deba hacerlo con las bibliotecas de soporte de su software, entonces no hay ningún problema en el uso de deprecatedmétodos.
2. No.

Si, esta mal.

Los métodos o clases en desuso se eliminarán en futuras versiones de Java y no se deben usar. En cada caso, debería haber una alternativa disponible. Usa eso.

Hay un par de casos en los que tiene que usar una clase o método en desuso para cumplir con un objetivo del proyecto. En este caso, realmente no tiene más remedio que usarlo. Las versiones futuras de Java pueden romper ese código, pero si es un requisito, debe vivir con eso. Probablemente no sea la primera vez que tiene que hacer algo mal para cumplir con un requisito del proyecto, y ciertamente no será la última.

Cuando actualiza a una nueva versión de Java o alguna otra biblioteca, a veces un método o una clase que estaba usando se vuelve obsoleto. Los métodos obsoletos no son compatibles, pero no deberían producir resultados inesperados. Sin embargo, eso no significa que no lo harán, así que cambie su código lo antes posible.

El proceso de desaprobación está ahí para garantizar que los autores tengan tiempo suficiente para cambiar su código de una API anterior a una nueva. Aprovecha este tiempo. Cambie su código lo antes posible.

No está mal, pero algunos de los métodos en desuso se eliminan en las futuras versiones del software, por lo que posiblemente terminará con un código que no funciona.

¿Es incorrecto utilizar métodos o clases obsoletos en Java? "

No está mal como tal, pero puede ahorrarle algunos problemas. Aquí hay un ejemplo en el que se desaconseja encarecidamente utilizar un método obsoleto:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

¿Por qué Thread.stop está en desuso?

Porque es inherentemente inseguro. Al detener un subproceso, se desbloquean todos los monitores que ha bloqueado. (Los monitores se desbloquean a medida que la excepción ThreadDeath se propaga por la pila). Si alguno de los objetos previamente protegidos por estos monitores estaba en un estado inconsistente, otros hilos ahora pueden ver estos objetos en un estado inconsistente. Se dice que tales objetos están dañados. Cuando los hilos operan en objetos dañados, puede producirse un comportamiento arbitrario. Este comportamiento puede ser sutil y difícil de detectar, o puede ser pronunciado. A diferencia de otras excepciones no verificadas, ThreadDeath mata los hilos en silencio; por lo tanto, el usuario no tiene ninguna advertencia de que su programa puede estar dañado. La corrupción puede manifestarse en cualquier momento después de que ocurra el daño real, incluso horas o días en el futuro.

¿Qué sucede si no cambia ningún método y ejecuta mi aplicación con las advertencias que tengo? ¿Creará algún problema de rendimiento?

No debería haber problemas en términos de rendimiento. La API estándar está diseñada para respetar cierta compatibilidad con versiones anteriores, por lo que las aplicaciones se pueden adaptar gradualmente a las versiones más recientes de Java.

¿Es incorrecto usar métodos o clases obsoletos en Java? No está "mal", sigue funcionando, pero evítelo tanto como sea posible.

Supongamos que hay una vulnerabilidad de seguridad asociada con un método y los desarrolladores determinan que es una falla de diseño. Entonces pueden decidir desaprobar el método e introducir la nueva forma.

Entonces, si todavía usa el método anterior, tiene una amenaza. Por lo tanto, tenga en cuenta la razón de la desaprobación y compruebe si le afecta.

¿Qué pasa si no cambia ningún método y ejecuta mi aplicación con las advertencias que tengo? ¿Creará algún problema de rendimiento?

Si la desaprobación se debe a un problema de rendimiento, sufrirá un problema de rendimiento, de lo contrario no hay razón para tener ese problema. Una vez más me gustaría señalar, tenga en cuenta la razón de la depreciación.

En Java es @Deprecated, en C # es [Obsoleto].

Creo que prefiero la terminología de C #. Simplemente significa que está obsoleto. Todavía puede usarlo si lo desea, pero probablemente haya una mejor manera.

Es como usar Windows 3.1 en lugar de Windows 7 si cree que Windows 3.1 es obsoleto. Todavía puede usarlo, pero probablemente haya mejores características en una versión futura, además de que las versiones futuras probablemente serán compatibles, la obsoleta no lo será.

Lo mismo para @Deprecated de Java: aún puede usar el método, pero bajo su propio riesgo, en el futuro, podría tener mejores alternativas y es posible que ni siquiera sea compatible.

Si está utilizando código que está en desuso, generalmente está bien, siempre y cuando no tenga que actualizar a una API más nueva; el código en desuso podría no existir allí. Sugiero que si ve algo que está usando código obsoleto, actualice para usar las alternativas más nuevas (esto generalmente se señala en la anotación o en un comentario obsoleto de Javadoc).

Editar: Y como señaló Michael, si la razón de la depreciación se debe a una falla en la funcionalidad (o porque la funcionalidad ni siquiera debería existir), entonces, obviamente, uno no debería usar el código en desuso.

Por supuesto que no, ya que todo Java se está quedando @Deprecated :-) puede usarlos mientras dure Java. De todos modos, no notaré ninguna diferencia, a menos que sea algo realmente roto. Significado: hay que leer al respecto y luego decidir.

Sin embargo, en .Net, cuando algo se declara [Obsoleto], ve y lee sobre ello de inmediato, incluso si nunca lo has usado antes; tienes aproximadamente un 50% de posibilidades de que sea más eficiente y / o más fácil de usar que el reemplazo :-))

Por lo tanto, en general, puede ser bastante beneficioso ser tecnoconservador en estos días, pero primero debe hacer su tarea de lectura.

Siento que significa método obsoleto; Hay un método alternativo disponible que es mejor en todos los aspectos que el método existente. Es mejor usar el buen método que el método antiguo existente. Por compatibilidad con versiones anteriores, los métodos antiguos se dejan en desuso.