Función de idioma: Clases selladas (JEP 409)

Las clases selladas pueden ser la característica finalizada más esperada en JDK 17, y fueron vistas previas en JDK 16. En resumen, las clases selladas restringen qué otras clases (o interfaces) pueden extenderlas. Como JP 409 describe, una clase o interfaz sellada puede ser extendida o implementada solo por aquellas clases e interfaces autorizadas para hacerlo. Una clase se sella aplicando el sellado modificador de su declaración. Entonces, después de cualquier extiende y implementos cláusulas, la permisos La cláusula especifica las clases que pueden extender la clase sellada. Si a esas clases no se les permite expresamente hacer cambios, no pueden hacer cambios.

¿Por qué debería importarte? Según Aurelio García-Ribeyro, director de administración de productos de Java SE, "las clases selladas me permiten crear un conjunto de opciones que sé que es finito, y eso simplifica el código porque puedo tratar las clases como si fueran enumeraciones".

Tener clases selladas, dice, elimina la preocupación de que algún otro código pueda anular su código o modificar su comportamiento de maneras que no puede anticipar. “Crea una garantía de que nadie puede mejorar una biblioteca de una manera que rompa mi código en el futuro”.

Actualización de la biblioteca principal: filtros de deserialización específicos del contexto (JEP 415)

Los filtros de deserialización específicos del contexto se basan en una característica introducida en Java 9 (ver JEP 290: Filtrar datos de serialización entrantes). Ese antiguo JEP ofrecía filtros de deserialización por flujo intercambiables y un filtro estático para toda la JVM. Desafortunadamente, los filtros por transmisión no escalaron bien y es difícil actualizar los filtros después de enviar el código. Los filtros de JEP 290 tampoco pueden imponer el filtrado en las operaciones de deserialización realizadas por bibliotecas de terceros en una aplicación. El filtro de toda la JVM estaba limitado porque se especificaba solo una vez, al inicio, y en ocasiones era demasiado inclusivo o demasiado restrictivo.

La nueva funcionalidad en JEP 415 se presenta como una fábrica de filtros para toda la JVM. Los filtros son dinámicos y específicos del contexto. Para compatibilidad con versiones anteriores, si no se establece una fábrica de filtros, la fábrica integrada devuelve un filtro estático para toda la JVM, si se configuró uno.

El problema, dice García-Ribeyro, es que cada vez que un desarrollador creaba una canalización, tenía que definir cuál era el filtro, incluida una lista de permitidos y una lista de denegados. Sin embargo, según García-Ribeyro, “si estoy usando una biblioteca de terceros, ellos están usando sus propios flujos. Podía definir un filtro para toda la JVM, pero tenía que saber, con anticipación, todo lo que la biblioteca quería hacer. Esto requirió mucho trabajo”.

Por el contrario, JEP 415 proporciona una fábrica de filtros. “Con una fábrica de filtros, los filtros de deserialización ahora son inmensamente más fáciles de usar”, dice, “hasta el punto de que esta es la única característica que ya estamos reelaborando y modernizando, hasta JDK 11 y JDK 8”.

No hay un marco de tiempo establecido para que JEP 415 vuelva a la versión anterior de Java, pero García-Ribeyro insiste: "Estamos trabajando intensamente en ello".

Actualización de la biblioteca principal: nueva canalización de renderizado de macOS (JEP 382)

¿Usas una Mac? Sí, no sé qué haría sin mi MacBook Pro con i7 de cuatro núcleos. La nueva canalización de renderizado de macOS descrita por JPY 382 es bastante simple: aleja los gráficos 2D de la JVM del uso de la API Apple OpenGL en desuso a la nueva API de metal de Apple. Por supuesto, si está utilizando Java para cargas de trabajo de back-end, es probable que esto no le importe.

Apple comenzó a eliminar OpenGL en macOS Mojave 10.14, advirtiendo: “Las API en los marcos OpenGL y OpenCL están obsoletas y permanecen presentes por motivos de compatibilidad. Haz la transición a Metal si tu aplicación usa OpenGL u OpenCL”.

Este cambio se aplica a las Mac basadas en Intel y ARM. Este es un cambio oculto. Como dice la documentación de JEP 382, “Los cambios se limitan al código específico de macOS e incluso allí solo se actualiza una cantidad mínima de código compartido entre Metal y OpenGL. No introdujimos nuevas API de Java, ni cambiamos ninguna API existente”.

La documentación JEP 382 señala además: “Apple afirma que el marco Metal, su reemplazo para OpenGL, tiene un rendimiento superior. Para la API Java 2D, este suele ser el caso con algunas excepciones”.

Por ahora, la JVM de Java 17 usará de manera predeterminada OpenGL; usará Metal solo si OpenGL no está presente o si el usuario activa un interruptor de línea de comandos. García-Ribeyro pide, sin embargo, que los usuarios de Mac prueben el nuevo código. “Queremos que active esta nueva canalización de renderizado. Debería ser más rápido que, o al menos igual, el rendimiento de gráficos existente en Mac”.

Vista previa: Coincidencia de patrones para interruptor (JEP 406)

Probablemente he oído más sobre coincidencia de patrones para cambiar (JE 406) que cualquier otra función de JDK 17, y García-Ribeyro también está entusiasmado con ella. “Esta característica hace que Java sea mejor para todos”, dice, “y en un par de lanzamientos, se convertirá en parte del estándar Java”.

Este PEC se basa en el trabajo de coincidencia de patrones para en vez de (JEP 394), que se finalizó para JDK 16. La nueva característica ofrece dos grandes beneficios.

• Hace cambiar declaraciones mucho más programables y flexibles al permitir que aparezcan patrones en caso etiquetas. Para citar la documentación de la JEP, “Solo se puede cambiar en valores de unos pocos tipos: tipos numéricos, tipos de enumeración y Cuerda - y solo puede probar la igualdad exacta contra constantes. Podríamos querer usar patrones para probar la misma variable contra un número de posibilidades, tomando una acción específica en cada una, pero dado que el cambiar no admite eso, terminamos con una cadena de si... más pruebas.”
• Proporciona un mecanismo más elegante (y fácil de usar para desarrolladores) para manejar condiciones nulas. De nuevo, para citar: “Tradicionalmente, cambiar declaraciones y expresiones lanzan Excepción de puntero nulo si la expresión del selector se evalúa como nula, entonces la prueba de nula debe realizarse fuera del interruptor... Esto era razonable cuando cambiar admite sólo unos pocos tipos de referencia. Sin embargo, si cambiar permite una expresión de selector de cualquier tipo, y las etiquetas de casos pueden tener patrones de tipo, entonces la prueba nula independiente se siente como una distinción arbitraria, e invita a una repetición innecesaria y a la oportunidad de error”.

Espero que la mayoría de los desarrolladores descubran que cuando intentan la coincidencia de patrones para cambiar, dirán: "¿Dónde has estado toda mi vida?"