Haz todo lo posible por interpretar el código correctamente previamente a aplicarlo a tu trabajo si ttienes algo que aportar puedes compartirlo con nosotros.
Solución:
Paso 1: anuncia la eliminación
Uno puede pensar que desaprobar una API significa anunciar que se eliminará, pero este no es el único caso de uso (como se describe en artículos relevantes de, por ejemplo, Java 7 y Java 9):
La API es peligrosa (por ejemplo, la
Thread.stopmétodo).Hay un simple cambio de nombre (por ejemplo, AWT
Component.show/hidereemplazado porsetVisible).En su lugar, se puede utilizar una API mejor y más nueva.
La API obsoleta se eliminará.
Para complicar aún más las cosas, antes de Java 9, nunca se eliminó ninguna API obsoleta en el JDK (consulte 20 años de obsolescencia de Java), por lo que es comprensible que los desarrolladores no se tomen en serio la obsolescencia, ni en el JDK ni en ningún otro lugar.
Por lo tanto, debe comunicar claramente que la API realmente, realmente va a ser eliminado. La forma de hacerlo depende de la versión de Java con la que esté compilada su API.
Java 8 o inferior
En estas versiones de Java, no existe una forma formal de distinguir explícitamente los diversos casos de uso de obsolescencia. Lo mejor que puede hacer es agregar la etiqueta Javadoc @deprecated y no solo dando el motivo de la desaprobación y enumerando alternativas, sino también anunciando explícitamente su intención de eliminar la API.
Java 9 o superior
Desde Java 9, con Enhanced Deprecation, ahora puede escribir
@Deprecated(forRemoval=)
para documentar explícitamente su intención. Creo que junto con Javadoc @deprecated (que debe detallar el motivo de la desaprobación y enumerar las alternativas), esta bandera estandarizada es una advertencia justa.
Con esta bandera puesta en true, el compilador advertirá por cada uso del elemento obsoleto de esta manera:
YourClass.java:: warning: [removal] in has been
deprecated and marked for removal
Esta advertencia está habilitada de forma predeterminada (en lugar de tener que habilitarse con -Xlint:deprecation) y es no suprimido con @SuppressWarnings("deprecation"). En cambio, uno tendría que suprimirlo con el nuevo @SuppressWarnings("removal"), lo que podría hacer que los desarrolladores lo piensen dos veces antes de hacerlo sin una buena razón.
Además, puede indicar explícitamente la versión de la biblioteca que introdujo la obsolescencia con
@Deprecated(since="")
Ver esto en Javadoc o en las fuentes puede ayudar a los desarrolladores a evaluar qué tan urgente es actualizar su código.
Paso 2a: advertencia de tiempo de ejecución
Si es factible para la situación, agregue un recordatorio de tiempo de ejecución: cuando se use la API obsoleta, haga que registre una advertencia en la consola o en el archivo de registro (usando cualquier mecanismo de registro que use) anunciando que esto ya no funcionará con la próxima versión principal. Para evitar el spam, solo puede registrarlo una vez (p. Ej. private static boolean warningLogged).
Paso 2b: análisis de código estático
Los analizadores de código estático como SonarQube (también disponible como servicio alojado) se pueden configurar para marcar cada una de estas advertencias. La regla de SonarQube “el código obsoleto no debe usarse” debería funcionar incluso si se suprime la advertencia de uso obsoleto del compilador.
SonarQube también rastrea cuándo se introdujo un determinado problema (es decir, una infracción de las reglas) (según el control de versiones) y puede filtrar interactivamente sus listas de problemas en función de esa fecha. Por ejemplo, puede enumerar todos los usos de código obsoleto que han estado en su base de código durante más de un año para que pueda priorizar el trabajo para corregirlos.
Paso 3: eliminar la API
En realidad, no eliminar la API daría a los usuarios de la API la impresión de que no necesitan molestarse en cambiar su código.
Una API obsoleta no es útil en la medida en que esté anotada con @Deprecated. Si los clientes de API aún pueden usarlo con éxito después de años de estar marcado como obsoleto, entonces es correcto decir que el proveedor de API no los está ayudando de ninguna manera práctica.
¿Existe una solución práctica a este problema?
Sí: deje que la desaprobación signifique la desaprobación y, después de un período de gracia, haga que la API obsoleta no esté disponible, si la eliminación es la forma correcta de solucionarlo. Si, por ejemplo, desaprueba una API con riesgos de seguridad, no eliminarla en una versión futura hace que la desaprobación sea inútil y puede considerarse que contribuye al problema.
los @Deprecated La anotación es poco más que documentación, que, incluso como ha señalado, otros desarrolladores pueden simplemente ignorar.
La desaprobación de Java 9+ es quizás más informativa, pero la decisión final aún depende del desarrollador que consume la API, lo que no resuelve el problema.
¿Existe una solución práctica a este problema?
¿Práctico desde la perspectiva de quién?
Desde la perspectiva de los desarrolladores que rutinariamente ignoran / suprimen las advertencias de obsolescencia, ya tienen su “solución” … que es ignorar el problema. Pero la otra cara es que otras personas no pueden evitar que hagan eso. Pero la otra cara de la moneda es que … en última instancia … no es asunto de otras personas.
Desde la perspectiva de los desarrolladores que desean desaprobar las API que mantienen, ya tienen una solución. Solo hazlo. Luego, continúe con el siguiente paso eliminando las API obsoletas. La otra cara es que molestará a algunas personas y otras se quemarán. (Especialmente las personas que habitualmente ignoran / suprimen las advertencias de desaprobación. Pero consulte más arriba: eso es su problema.)
Desde la perspectiva de alguien cuya preocupación / responsabilidad es mantener la calidad / integridad del código de la base de código de una organización, sí, hay un problema. Pero la solución es relativamente sencilla:
- Prohibir el uso de código @suppress (“desaprobación”) `.
- Prohibir los scripts de compilación que desactivan las advertencias de obsolescencia.
- Haga cumplir lo anterior a través de complementos de servidor SCI, reglas de verificación de estilo personalizadas o (si quiere ser crudo) “grepping” el código fuente.
- Tome un palo grande (metafórico) a los programadores que son reincidentes.
¿Hay alguna función JRE / JDK planificada que pueda ayudar con esta situación?
Como se señaló, la compatibilidad con anotaciones mejorada de Java 9+ (consulte JEP 277):
- proporciona un etiquetado de obsolescencia más informativo, y
- proporciona una herramienta
jdeprscan) para buscar infracciones de obsolescencia en las API de Java SE.
Te mostramos comentarios y valoraciones
Si posees alguna sospecha y capacidad de ascender nuestro escrito puedes añadir una explicación y con deseo lo ojearemos.