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


153

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?


77
¿Continuaría manejando su vehículo 1955 Volkswagen Beetleincluso si se lo ofrecen Corvette Stingray, gratis? (0:
KMån

75
@KMan, ¿está comparando un automóvil europeo con un automóvil estadounidense ?;)
ponzao

2
@Ponzao y 4otros: ¡ Te tengo ! (0;
KMån

2
¿Incorrecto? ¿Estamos hablando de mortal o simplemente de venganza aquí?
FastAl

55
@Alexander no vota por su comentario, por lo que también hace +1 por el suyo;) en cualquier caso, es difícil que el nuevo código sea 1000 mejor que el código anterior. ¡La comparación sería mejor entre 1955 Volkswagen Beetley 1956 Volkswagen Beetlecon neumáticos nuevos que no sabes cuándo se romperán!
Aleks

Respuestas:


265

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 ().


55
La siguiente desaprobación más divertida en la API de Java sería setMultiClickThreshhold (int threshhold) y getMultiClickTreshhold () en AbstractButton (Swing). ¡Prepárate para esos dos! ;)
JavaTechnical

3
Necesitamos hacer esto con HTTP REFERER. Es enloquecedor: en.wikipedia.org/wiki/HTTP_referer
kmiklas

1
@DaveMcClelland, hizo 70 desde 69: D;)
VdeX

28

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.


1
¿Cómo puede estar seguro de que no hay cambios en el rendimiento? La depuración podría deberse , por ejemplo, a un cambio de una estructura de datos interna, por ejemplo, de un HashSet a un TreeSet, por ejemplo.
aioobe

@aioobe: según tengo entendido, el OP preguntó si llamar al código en desuso tiene algún problema de rendimiento, lo que no significa que no cambie el código de byte producido (antes de 1.5 estaba en javadoc, ahora la anotación está en uso, pero todavía no hay cambio en el rendimiento)
abyx

Al pasar de una versión de una biblioteca a otra, no hay garantía de que el código de bytes de un método en la nueva versión sea idéntico al código de bytes del mismo método en la versión anterior.
aioobe

@aioobe: hay una garantía de que simplemente dejarlo en desuso no cambiará el código de bytes, que es lo que creo que significaba el OP. Por supuesto, el código en sí cambia, por lo que despreciamos el código.
abyx

Si sigue utilizando la misma versión que antes, no hay cambios. Pero si utiliza una versión más nueva de la biblioteca, y no han desaprobado la API, PODRÍA haber una alteración en el rendimiento, si la implementación subyacente se altera drásticamente y la nueva API se aprovecha de ella, mientras que la API anterior no es tan eficiente como solía ser, contra esta nueva estructura.
gregturn

21

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


¿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


3
"Desaprobado" es del latín "de" + "precare" que significa "rezar contra". Cuando algo se describe como obsoleto, un Estándar está rezando, rogando, que no lo uses; es una advertencia de que puede eliminarse en una versión futura de ese Estándar. Tenga en cuenta que se requiere que una característica obsoleta se implemente completamente en cualquier implementación de la versión actual de ese Estándar. Sin embargo, su mención del humor autocrítico es un poco descabellado; "autocrítica" en ese sentido es una corrupción de "autocrítica", que tiene una derivación y un significado diferentes.
dajames

17

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


11

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


1
A juzgar por la experiencia, "obsoleto" realmente significa "no deberías usar esto más, pero estará disponible para siempre". Al menos para la API estándar de Java, no estoy al tanto de ningún método o clase que realmente se elimine después de ser obsoleto.
Michael Borgwardt

1
@Michael Bueno, en la práctica, las API raramente eliminan funciones obsoletas porque podrían quedar obsoletas durante diez años con compiladores que emiten "ADVERTENCIA: DEJEN DE USAR ESTE TONTO", y la gente todavía se daría por vencida el día que finalmente las eliminaron. Creo que en desuso se supone que significa "algún día queremos sacar esto, así que por favor deja de usarlo", incluso si en la práctica rara vez sucede realmente
Michael Mrozek

@Michael Mrozek: No estoy de acuerdo con la declaración It certainly doesn't create a performance issue; es demasiado subjetivo para decir eso.
KMån

1
@KMan Una función que se marca como obsoleta de alguna manera no la hace menos eficiente de lo que era antes de ser marcada; se ejecutará exactamente igual que antes
Michael Mrozek

@Michael Borgwardt: así es como funciona en la mayoría de los idiomas estandarizados. Y, por supuesto, si se eliminara algo obsoleto del estándar, las implementaciones populares lo mantendrían como una extensión.
David Thornley

8

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í.


8

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


4
  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.

3

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.


2

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.


Removed? Vea la definición stackoverflow.com/questions/2941900/…
KMån

1
@KMan: en el enlace que publicó está escrito: "El método se mantiene en la API por compatibilidad con versiones anteriores por un período de tiempo no especificado, y en futuras versiones se puede ELIMINAR". He escrito lo mismo: algunos de los métodos obsoletos posiblemente se eliminen en el futuro cercano o lejano.
Petar Minchev

2

¿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.


2

¿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.


2

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.


1
"Si está utilizando código que está en desuso, está bien, siempre y cuando no tenga que actualizar a una API más nueva", no del todo. Observe por qué Thread.stop () está en desuso y verá que no está bien en ninguna versión de JRE.
Michael

Ok, más bien debería decir "generalmente" bien (actualizará ese bit) :) Por lo tanto, úselo bajo su propio riesgo. Obviamente, si la razón para despreciarlo es detener una falla en su funcionalidad, tiene sentido no usarlo. Sin embargo, en general, está bien usar un método obsoleto. Entonces, ja, todo depende de la razón de la depreciación. Cierto.
jamiebarrow

1

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.