JDK 14: las nuevas características en Java 14

Java Development Kit (JDK) 14 está tomando forma, con tres características propuestas oficialmente y otra esperada. La transmisión de eventos JFR (JDK Flight Recorder), para exponer los datos del registrador de vuelo para monitoreo continuo, ahora se ha propuesto para el lanzamiento.

JDK 14 está programado para un lanzamiento de producción el 17 de marzo de 2020, luego de la cadencia de lanzamiento de seis meses establecida para Java. JFR Event Streaming sigue un NullPointerExceptions La mejora y los búferes de bytes de mapeo de archivos no volátiles como características dirigidas oficialmente para JDK 14. Una cuarta característica esperada, cambiar expresiones, aún no se ha propuesto oficialmente.

Aquí hay descripciones de las características que se espera que se orienten en JDK 14 hasta ahora:

  • JFR Event Streaming proporciona una API para el consumo continuo de datos JFR de aplicaciones tanto en proceso como fuera de proceso. JFR es una herramienta para recopilar perfiles y datos de diagnóstico sobre una aplicación Java en ejecución. La propuesta de transmisión de eventos registra el mismo conjunto de eventos que para el caso sin transmisión, con una sobrecarga de menos del uno por ciento si es posible. La transmisión de eventos debe coexistir con grabaciones sin transmisión, tanto basadas en disco como en memoria. Motivar esta propuesta es una situación en la que HotSpot VM emite más de 500 puntos de datos utilizando JFR, la mayoría de ellos disponibles solo mediante el análisis de archivos de registro. Actualmente, un usuario debe iniciar una grabación, detenerla, volcar el contenido en el disco y luego analizar el archivo de grabación. Esto funciona bien para la creación de perfiles de aplicaciones, pero no para fines de monitoreo. Un ejemplo de uso de monitoreo es un tablero que muestra actualizaciones dinámicas de datos. Hay una sobrecarga con la creación de una grabación, como copiar datos del repositorio del disco a un archivo de grabación separado. Si hubiera una manera de leer los datos que se graban desde el repositorio del disco sin crear un nuevo archivo de grabación, se podría evitar gran parte de la sobrecarga.
  • La mejora prevista para NullPointerExceptions pertenece a mejorar la usabilidad de las excepciones generadas por la JVM al describir exactamente qué variable era nula. Los autores de la propuesta buscan proporcionar información útil a los desarrolladores y al personal de soporte sobre la finalización prematura de un programa y mejorar la comprensión del programa al asociar más claramente una excepción dinámica con el código de programa estático. Un objetivo es reducir la confusión y la preocupación que los desarrolladores tienen sobre NullPointerExceptions.
  • Los búferes de bytes mapeados no volátiles agregarían nuevos modos de mapeo de archivos específicos de JDK que permiten utilizar la API FileChannel para crear MappedByteBuffer instancias que se refieren a memoria no volátil (NVM). NVM permite a los programadores construir y actualizar el estado del programa a través de las ejecuciones del programa sin incurrir en los costos significativos de copia o traducción que generalmente requieren las operaciones de entrada y salida. Esto es particularmente significativo para los programas transaccionales. Por lo tanto, el objetivo principal de esta propuesta de mejora JDK es garantizar que los clientes puedan acceder y actualizar NVM desde un programa Java de manera coherente y eficiente. Un objetivo secundario es implementar este comportamiento de confirmación utilizando una API interna restringida de JDK definida en la clase Inseguro, por lo que puede ser reutilizado por otras clases que no sean MappedByteBuffer eso puede necesitar comprometerse con NVM. Otro objetivo es permitir que las API existentes realicen un seguimiento de los almacenamientos intermedios asignados a través de NVM para el monitoreo y la administración. Las plataformas de SO / CPU de destino incluyen Linux / x64 y Linux / AArch64.
  • Las expresiones de conmutación simplifican la codificación extendiendo cambiar para que pueda usarse como una declaración o una expresión. Se espera que las expresiones de cambio sean una característica permanente en JDK 14, después de una vista previa tanto en JDK 12 como en JDK 13. Las expresiones de cambio también se preparan para el uso de la coincidencia de patrones en cambiar, lo que permitirá a los desarrolladores extraer condicionalmente componentes de objetos de manera más concisa y segura.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *