La versión de soporte a largo plazo (LTS) del lenguaje Java y la plataforma de tiempo de ejecución Java 17 se lanzó el 14 de septiembre de 2021. Aprendamos qué hay de nuevo en Java 17 y si debe actualizar.
Muchas aplicaciones utilizan versiones anteriores de Java, incluidas las versiones LTS anteriores de Java: Java 11 y Java 8.
¿Por qué las empresas deberían actualizarse a la versión más actual de Java? La actualización a Java 17 requiere esfuerzo, principalmente para aprovechar al máximo las nuevas características y funciones dentro de la JVM.
Muchas empresas utilizan Docker y Imágenes de Docker para cambiar a Java 17 fácilmente con el mínimo esfuerzo y tiempo. Los desarrolladores pueden definir sus canalizaciones de implementación / integración continua (CI / CD) y ejecutar todo en imágenes de Docker. Esto no afectará a otros equipos que utilicen versiones anteriores de Java, ya que pueden utilizar imágenes antiguas de Docker.
JAVA 17 Features
Compatibilidad con macOS y AArch64
Una de las características críticas de JVM agregadas a esta versión es mejorar el soporte para macOS en la arquitectura AArch64 usando JEP 391. Soportará la última serie de procesadores (M1) que Apple lanzó con sus computadoras el año pasado.
No es necesariamente un gran problema para los usuarios de esas plataformas, ya que algunos proveedores han lanzado versiones de JDK que admiten esta arquitectura e incluso devuelven el soporte desde Java 8. Sin embargo, el sello oficial de aprobación es esencial para garantizar el mantenimiento y el soporte futuros de la plataforma. En comparación, se ha agregado soporte para la plataforma Linux / AArch64 a Java 9 y Windows / AArch64 en Java 16.
Clases Selladas
Sealed Classes es una función que se introdujo en Java 17. La función de Sellado Classes ha finalizado su fase de prueba y se ha convertido en una plataforma y lenguaje oficial en Java 17. Permite a un desarrollador especificar los subtipos permitidos que puede tener un tipo y evitar que otros lo amplíen o implementen de una manera que no está prevista.
Las clases selladas también permiten que el compilador genere errores en tiempo de compilación cuando intentas convertir un tipo no sellado en un subtipo no permitido. Java 17 también trae una nueva canalización de renderizado para aplicaciones AWT / Swing que se ejecutan en macOS usando la API de Apple Metal en lugar de OpenGL. Tiene una API mejorada y funciones mejoradas para generar números aleatorios.
Changes, Deletions, and Limitations in Java 17
Java 17 también trae varios cambios, eliminaciones y nuevas limitaciones.
Encapsulación de componentes internos de JDK
Un cambio es la conclusión del proceso de encapsulación de JDK Internals. La primera vez que se introdujo fue dentro de Java 9 y daría advertencias durante el tiempo de ejecución cuando un usuario intentara usar la reflexión o similar para eludir las restricciones habituales sobre el uso interno. API. También se agregaron argumentos en la línea de comandos para regular este comportamiento.
A partir de Java 9, se han creado varias API para ofrecer una forma uniforme de realizar las tareas más utilizadas; los usuarios utilizarían estas API internamente. Con Java 16, el valor predeterminado se cambió de una advertencia a deshabilitar el acceso para lanzar una excepción. Sin embargo, utiliza el argumento de la línea de comandos para modificar el comportamiento.
Con Java 17, se elimina el argumento de la línea de comandos y es posible desactivar esta restricción. Esto significa que todo el acceso no autorizado a esas API internas ahora está protegido.
Semántica de punto flotante siempre estricta
Una "eliminación" adicional se puede describir como la reintroducción de la semántica de coma flotante siempre estricta. Java 1.2 introdujo modificaciones a la semántica de punto flotante predeterminado en Java que permite que la JVM intercambie una pequeña cantidad de precisión en los cálculos de punto flotante para mejorar el rendimiento. En las clases y métodos donde se tenía que usar semántica estricta, un strictfp se agregó la palabra clave. Desde entonces, se han introducido varios tipos de conjuntos de instrucciones en las CPU, lo que hace que se utilice una semántica de coma flotante estricta sin costes innecesarios. Se ha eliminado la necesidad de implementar una semántica estricta o por defecto.
Java 17 elimina la semántica predeterminada anterior y todas las operaciones de punto flotante se ejecutan estrictamente. El término strictfptodavía está presente. Sin embargo, no tiene ningún efecto y provoca una advertencia en compilar en las transacciones.
Recopilación anticipada (AOT)
Java 9 introdujo la compilación anticipada (AOT) como una característica experimental que utiliza el compilador Graal, y se escribió un código JIT usando Java. Java 10 hizo que el compilador Graal se pudiera usar como compilador JIT en OpenJDK al incorporar la interfaz JVMCI. Desde su lanzamiento, ha sido una gran mejora. El compilador Graal ha experimentado avances tremendos y tiene su JVM bajo el nombre de GraalVM.
Activación RMI
La activación de RMI se eliminó en JEP 407 después de su eliminación de Java 8 y finalmente en desuso y marcado como un requisito para su eliminación dentro de Java 15. La activación de RMI proporcionó un método para habilitar objetos distribuidos bajo demanda mediante recursos RMI. Sin embargo, vio un uso mínimo y una mejor alternativa está disponible en el presente. El resto de RMI no se ve afectado por la eliminación de la parte de Activación.
Eliminación de la API de applet
La API de applet finalmente ha sido designada para su eliminación por JEP 398, inicialmente eliminado dentro de Java 9. La API de Applet proporcionó una forma de integrar los controles de Java AWT / Swing en una página web dentro de un navegador. Sin embargo, ningún navegador moderno puede admitir esto, lo que significa que los Applets han sido esencialmente inaccesibles durante la última década más o menos.
Security Manager
La desaprobación más importante es que es el administrador de seguridad ( JEP 411). Security Manager se ha utilizado durante un tiempo desde Java 1.0. Fue diseñado para restringir lo que Java podía hacer localmente en la máquina, como limitar el acceso a redes, archivos y otros recursos de red. También intenta proteger el código en el que no se confía bloqueando la reflexión y las API específicas.
El final de Security Manager comenzó en Java 12. Se agregó un argumento de línea de comandos para bloquear el uso del administrador de seguridad en tiempo de ejecución. El cambio realizado en Java 17 significa que se generará una advertencia de tiempo de ejecución en la JVM al intentar configurar un Administrador de seguridad, ya sea desde la línea de comandos o dinámicamente en tiempo de ejecución.
Incubator and Preview Features
Muchos se preguntaron si Java 17 tendría alguna función de vista previa e incubadora, considerando que Java 17 fue promocionado como una versión soportada a largo plazo. ¡Java 17 tiene dos módulos de incubadora y una función de vista previa!
API de vectores
API de vectores ( JEP 414) se encuentra actualmente en su segunda fase de incubadora. La API permite a los desarrolladores definir el cálculo vectorial que el compilador JIT luego convertirá en la instrucción vectorial adecuada compatible con la arquitectura de la CPU en la que se ejecuta la JVM (por ejemplo, utilizando los conjuntos de instrucciones SSE o AVX).
Antes, los desarrolladores tenían que usar funciones escalares o crear bibliotecas nativas específicas para la plataforma. La implementación de la API de Vector en Java también proporciona un mecanismo de respaldo perfecto que era complicado en versiones anteriores.
La estandarización de la API Vector permite que las clases dentro del JDK la utilicen. Los métodos de desajuste () de Java Arrays podrían cambiarse para ejecutarse en Java, eliminando el requisito de mantener y escribir implementaciones específicas de múltiples plataformas dentro de la JVM.
API de memoria y función ajena
Una característica adicional de la incubadora se llama API de memoria y función ajena ( JEP 412). Es una evolución y fusión de otros dos módulos incubadoras de Java 16 que es The Foreign Linker API ( JEP 389) y API de memoria externa ( JEP 393). Ambos proporcionan acceso a la memoria nativa y al código mediante el uso de programación de tipo estático escrito en Java.
Coincidencia de patrones para Switch
La última característica de la vista previa del idioma incluida en Java 17 es la inclusión de Pattern Matching para Switch ( JEP 406). Esta característica de lenguaje expande las expresiones y declaraciones de cambio según el tipo, similar a la sintaxis utilizada a través de Pattern Matching (JEP 394), que se convirtió en estándar con Java 16.
En el pasado, si deseaba realizar diferentes acciones basadas en la naturaleza dinámica de un objeto, se le pedía que construyera una cadena if-else utilizando una instancia de comprobaciones como:
String type(Object o) {
if (o instanceof List) {
return "A List of things.";
}
else if (o instanceof Map) {
return "A Map! It has keys and values.";
}
else if (o instanceof String) {
return "This is a string.";
}
else {
return "This is something else.";
}
}Combinando la expresión del conmutador y la nueva función de coincidencia de patrones para conmutadores, el proceso se puede reducir a algo similar a:
String type(Object o) {
return switch (o) {
case List l -> "A List of things.";
case Map m -> "A Map! It has keys and values.";
case String s -> "This is a string.";
default -> "This is something else.";
};
}Como habrás notado, existe la declaración de una variable en el proceso de verificación. Al igual que las otras variables en Pattern, la coincidencia de instancia indica que este objeto fue verificado de tipo y lanzado y está disponible en la variable dentro de su área actual.
La función de vista previa es otro paso hacia la coincidencia de patrones. El siguiente paso es incluir la capacidad de deconstruir matrices y registros.
Should You Upgrade to Java 17?
Sí, debe actualizar constantemente a la versión más reciente, pero no tan pronto como el primer día. Es posible que el software y las bibliotecas que está utilizando no se hayan actualizado para incluir compatibilidad con Java 17, por lo que es posible que deba esperar un tiempo hasta que finalice.
Si está atascado con una versión LTS de Java como Java 8 o Java 11, existen numerosas opciones dentro del lenguaje y dentro de la propia JVM que requieren una actualización hasta Java 17. Al ser una versión de mantenimiento a largo plazo, hay Existe una alta probabilidad de que su entorno de producción eventualmente se actualice también a Java 17.
Si está comenzando un proyecto completamente nuevo, o está en el proceso de preparar su proyecto y listo para Java 17, hacer el cambio a Java 17 más temprano que tarde es probablemente la opción más eficiente, ya que reduce los costos de mudanza. Esto también permite a los desarrolladores que trabajan en el proyecto utilizar todas las funciones más recientes y el lado de operaciones.
Puede aprovechar las muchas mejoras que se han producido en los últimos años, como el soporte mejorado para contenedores que se ejecutan en Java, así como nuevas implementaciones de recolectores de basura de baja latencia.
