Java 24: todas las novedades que debes conocer

La versión 24 del Kit de Desarrollo de Java (JDK) ya está aquí, y esta vez nos trae una cantidad importante de nuevas funcionalidades y mejoras que impactan en diversos aspectos del desarrollo con esta plataforma. Como tercera versión no LTS (Long-Term Support) desde JDK 21, JDK 24 continúa la cadencia de lanzamientos semestrales, ofreciendo a la comunidad Java acceso temprano a innovaciones y refinamientos.

Tiene un poco de todo, para todo el mundo:

Si eres desarrollador Java con experiencia, JDK 24 te ofrece herramientas y optimizaciones para construir aplicaciones más eficientes, seguras y preparadas para los desafíos del futuro. Funcionalidades como la reducción del tamaño de los encabezados de objeto, la carga anticipada de clases, y las mejoras en la concurrencia con hilos virtuales pueden traducirse en un mejor rendimiento y una menor huella de memoria para tus aplicaciones. Además, la introducción de la Class-File API abre nuevas posibilidades para el análisis y la manipulación del bytecode Java.

Si estás aprendiendo a programar con Java, el JDK 24 presenta un entorno de aprendizaje actualizado con las últimas características del lenguaje y la plataforma. La evolución hacia archivos de código fuente más simples y métodos main de instancia facilita tus primeros pasos en la programación Java, permitiendo una transición gradual hacia conceptos más avanzados. Las nuevas capacidades de pattern matching con tipos primitivos y los cuerpos de constructor más flexibles enriquecen las herramientas disponibles para escribir código más claro y conciso.

Finalmente, si lo tuyo es la arquitectura de software, JDK 24 introduce cambios que influyen en el diseño y la estrategia de las aplicaciones a gran escala. La preparación para restringir el uso de JNI, la eliminación del Security Manager, y la incorporación de algoritmos criptográficos resistentes a ataques cuánticos son aspectos cruciales para la seguridad y el uso a largo plazo de los sistemas. La mejora en el manejo de la concurrencia con hilos virtuales y la estructuración de tareas también abren nuevas vías para construir aplicaciones más resilientes y escalables.

Vamos a echarle un vistazo a la larga lista de novedades para ver qué te puede interesar. Se incluyen enlaces a cada cosa relevante para que puedas profundizar si te interesa.

🚀 Si estás aprendiendo Java y quieres hacerlo BIEN, hazlo con campusMVP.es, a tu ritmo y de la mano de un reconocido experto con la formación online: Desarrollo de aplicaciones con la plataforma Java.

Rendimiento optimizado en Java 24: Aplicaciones más ágiles

La versión 24 del JDK incorpora una serie de mejoras fundamentales destinadas a reducir la huella de memoria y mejorar los tiempos de inicio de las aplicaciones Java. Estas optimizaciones se abordan desde diferentes ángulos, afectando tanto a la estructura interna de los objetos como al proceso de carga y gestión de la memoria:

• Carga y enlazado anticipado de clases: para mejorar el tiempo de inicio de las aplicaciones, JDK 24 introduce Ahead-of-Time Class Loading & Linking (JEP 483). Esta funcionalidad permite que las clases de una aplicación estén instantáneamente disponibles en un estado cargado y enlazado cuando se inicia la JVM (HotSpot u OpenJDK). Esto se logra monitorizando la aplicación durante una ejecución y almacenando las formas cargadas y enlazadas de todas las clases en una caché para su uso en ejecuciones posteriores. Este JEP extiende también la funcionalidad de Class-Data Sharing (CDS), añadiendo las clases cargadas y enlazadas a la caché, denominándola "AOT cache". Según las pruebas realizadas por Oracle, con la referencia de un benchmark de compilador Java, se ha observado una reducción del 26% en el tiempo de inicio con la utilización de esta caché. Los frameworks como Spring Boot podrían beneficiarse especialmente de esta característica debido al gran número de clases que cargan. Para generar esta caché, se requiere una ejecución de entrenamiento que registre la configuración AOT y posteriormente una ejecución de creación de la caché. La utilización de la caché AOT está sujeta a ciertas restricciones, como la necesidad de usar la misma versión de JDK, sistema operativo, arquitectura CPU y classpath que la ejecución de entrenamiento.
• Reducción del tamaño de los encabezados de objeto: una de las novedades experimentales más significativas es la introducción de la funcionalidad Compact Object Headers (JEP 450). En arquitecturas de 64 bits, los encabezados de los objetos en la JVM ocupan entre 96 y 128 bits. El objetivo de esta característica es reducir este tamaño a 64 bits. Esta reducción puede llevar a una disminución del tamaño del heap, lo que a su vez mejora la densidad de despliegue de las aplicaciones y aumenta la localidad de los datos. Es importante destacar que esta característica es experimental y debe habilitarse explícitamente mediante las opciones -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders.
• Optimización de las barreras del recolector G1: el recolector de basura G1 también recibe mejoras con Late Barrier Expansion for G1 (JEP 475). Esta optimización simplifica la implementación de las barreras de G1, que registran información sobre los accesos a la memoria de la aplicación, retrasando su expansión en la canalización de compilación de C2 JIT.
• Eliminación del modo no generacional de ZGC: otra novedad relacionada con la gestión de memoria es la eliminación del modo no generacional del recolector de basura Z (ZGC) (JEP 490). Esta decisión simplifica el diseño y mantenimiento de ZGC, que ahora operará exclusivamente en modo generacional.
• El JEP 404, Generational Shenandoah (Experimental), introduce capacidades experimentales de recolección generacional al recolector de basura Shenandoah. El objetivo principal es mejorar el rendimiento sostenido, la resistencia a los picos de carga y la utilización de la memoria, buscando reducir la huella de memoria sostenida sin sacrificar las pausas cortas para hacer recolección de basura. Esta característica divide el heap de Java en dos generaciones, joven y vieja, aplicando principalmente los esfuerzos de GC en la generación joven donde se espera que la mayoría de los objetos mueran pronto. Aunque es experimental y no reemplaza el modo no generacional, se espera que beneficie a la mayoría de los casos de uso cuando esté disponible definitivamente (mientras puedes ir probándolo).

En conjunto, estas optimizaciones buscan ofrecernos la posibilidad de ejecutar aplicaciones Java con un menor consumo de recursos y tiempos de inicio más rápidos, lo que se traduce en una mejor experiencia de usuario y una mayor eficiencia en el despliegue.

Mejoras en concurrencia e hilos virtuales en java 24

JDK 24 trae también mejoras importantes para la programación concurrente en Java, especialmente en lo que respecta a los hilos virtuales y la concurrencia estructurada de las que ya te hemos hablado aquí cuando aparecieron. Estas novedades buscan simplificar el desarrollo de aplicaciones altamente concurrentes, haciéndolas más escalables, fiables y fáciles de observar.

Sincronización sin ataduras: virtual threads más ágiles

Una de las principales limitaciones de los hilos virtuales en versiones anteriores de JDK era su "pinning" a los hilos de plataforma cuando se utilizaban bloques o métodos synchronized. Este fenómeno impedía que el hilo virtual se desmontara de su hilo de plataforma subyacente durante una operación de bloqueo dentro de una sección sincronizada, lo que limitaba mucho la escalabilidad, ya que se agotaban los hilos de plataforma disponibles.

El JEP 491, Synchronize Virtual Threads without Pinning, aborda directamente este problema. En JDK 24, se ha modificado la implementación de la palabra clave synchronized para permitir que los hilos virtuales que se bloquean dentro de construcciones sincronizadas liberen su hilo de plataforma subyacente para que otros hilos virtuales puedan utilizarlo.

Esta mejora elimina casi todos los casos de "pinning" de hilos virtuales a hilos de plataforma, lo que supone un aumento considerable en el número de hilos virtuales que pueden manejar la carga de trabajo de una aplicación. Ahora, cuando un hilo virtual se bloquea al intentar adquirir un monitor o dentro de una sección synchronized, se desmonta de su hilo de plataforma, permitiendo que este último sea utilizado por otro hilo virtual. Cuando el monitor se libera, el hilo virtual se vuelve a montar (posiblemente en un hilo de plataforma diferente) para continuar su ejecución.

Esta optimización permite que las bibliotecas Java existentes que utilizan extensivamente synchronized puedan escalar mucho mejor con hilos virtuales sin necesidad de ser modificadas.

Además, se ha mejorado el diagnóstico de los casos restantes de "pinning". El evento jdk.VirtualThreadPinned del JDK Flight Recorder (JFR) se activará en estas situaciones, proporcionando información sobre la causa del "pinning" y la identidad del hilo de plataforma portador. La propiedad del sistema jdk.tracePinnedThreads, que se utilizaba para rastrear el "pinning" en secciones synchronized, se ha eliminado al no ser ya la principal causa de este problema.

Simplificando la programación concurrente

Para simplificar aún más la programación concurrente, JDK 24 continúa con la concurrencia estructurada a través de JEP 499, Structured Concurrency (Fourth Preview). Como su propio nombre indica, no es definitiva todavía y va por su cuarta iteración.

La concurrencia estructurada trata grupos de tareas relacionadas que se ejecutan en diferentes hilos como una única unidad de trabajo. Esto aporta varios beneficios importantes:

• Manejo de errores simplificado: si una subtarea dentro de un ámbito estructurado falla, el fallo puede propagarse automáticamente a la tarea principal, permitiendo un manejo de errores más centralizado y robusto.
• Cancelación coordinada: cuando una tarea principal necesita ser cancelada, todas sus subtareas concurrentes dentro del ámbito estructurado pueden ser canceladas de forma automática y coordinada, evitando fugas de hilos y simplificando la gestión del ciclo de vida de las tareas.
• Mejora de la fiabilidad: al imponer una estructura clara a las tareas concurrentes, se reduce la probabilidad de condiciones de carrera y otros problemas comunes en la programación concurrente no estructurada.
• Mayor observabilidad: la concurrencia estructurada facilita la comprensión de las relaciones entre las tareas concurrentes. Herramientas de observabilidad, como los volcados de hilos, pueden mostrar la jerarquía de tareas, lo que facilita la depuración y el análisis del rendimiento.

La API principal para la concurrencia estructurada es la clase StructuredTaskScope, que permite definir un ámbito dentro del cual se pueden bifurcar (fork) subtareas concurrentes. La tarea principal puede luego esperar (join) a que todas las subtareas finalicen (ya sea con éxito, fallo o cancelación). Se proporcionan políticas de apagado predefinidas, como ShutdownOnFailure (cancela las demás subtareas si una falla) y ShutdownOnSuccess (cancela las demás subtareas si una tiene éxito). Los desarrolladores también pueden crear sus propias políticas personalizadas.

La concurrencia estructurada se alinea especialmente bien con el uso de los hilos virtuales, ya que permite coordinar eficientemente un gran número de tareas ligeras, aprovechando al máximo su potencial de escalabilidad.

Evolución del lenguaje Java en Java 24: facilitando el desarrollo

JDK 24 también incluye mejoras y nuevas características en el lenguaje Java para hacerlo más flexible y accesible, aunque todas están todavía en preview, por lo que deberás las activar con --enable-preview en el compilador.

Tipos primitivos en patrones, instanceof y switch en Java

El JEP 488, Primitive Types in Patterns, instanceof, and switch (Second Preview), continúa mejorando el pattern matching permitiendo el uso de tipos primitivos en todos los contextos de patrones y extendiendo instanceof y switch para trabajar con todos los tipos primitivos.

Imagina que tienes una estructura para representar valores JSON donde los números se almacenan como double para mayor flexibilidad:

sealed interface JsonValue {
    record JsonString(String s) implements JsonValue {}
    record JsonNumber(double d) implements JsonValue {}
    record JsonObject(java.util.Map<String, JsonValue> map) implements JsonValue {}
}

JsonValue json = new JsonObject(java.util.Map.of("edad", new JsonNumber(30)));

if (json instanceof JsonObject(var map) &&
    map.get("edad") instanceof JsonNumber(double edadDouble)) {
    int edadInt = (int) edadDouble; // Necesitas un cast manual de double a int
    System.out.println("La edad es: " + edadInt);
}

En este caso, al usar instanceof, debías especificar el tipo exacto del componente del record (double edadDouble) y luego realizar un cast manual a int si querías usarlo como un entero. Esta conversión podría ser potencialmente lossy (perder información) sin que el lenguaje lo verificara en el momento de hacer el instanceof.

Con la mejora del JEP 488, ahora puedes usar patrones de tipo primitivo directamente en el instanceof, permitiendo una conversión segura (si es posible) y evitando el cast manual:

sealed interface JsonValue {
    record JsonString(String s) implements JsonValue {}
    record JsonNumber(double d) implements JsonValue {}
    record JsonObject(java.util.Map<String, JsonValue> map) implements JsonValue {}
}

JsonValue json = new JsonObject(java.util.Map.of("edad", new JsonNumber(30)));

if (json instanceof JsonObject(var map) &&
    map.get("edad") instanceof JsonNumber(int edadInt)) { // Patrón de tipo primitivo 'int' directamente
    System.out.println("La edad es: " + edadInt);
}

Ahora, el instanceof JsonNumber(int edadInt) intentará verificar si el double dentro de JsonNumber se puede convertir a int de forma segura (sin pérdida de información). Si es así, el patrón coincidirá y la variable edadInt estará disponible directamente como un int. Si la conversión no fuera segura (por ejemplo, si el double fuera 30.5), el patrón no coincidiría, permitiéndote manejar ese caso en otra rama de tu código sin riesgo de un cast implícito y potencialmente incorrecto.

Esto simplifica y hace más seguro el trabajo con tipos primitivos en la coincidencia de patrones, instanceof y switch, eliminando la necesidad de conversiones manuales en muchos casos y permitiendo verificaciones más expresivas y directas.

Cuerpos de constructor flexibles en Java

A través del JEP 492, Flexible Constructor Bodies (Third Preview), que permite que aparezcan sentencias antes de una invocación explícita al constructor (super(...) o this(...)) en los constructores. Estas sentencias no pueden referenciar la instancia en construcción, pero sí pueden inicializar sus campos, lo que facilita la creación de clases más robustas cuando se sobrescriben métodos.

Por ejemplo, tenemos una clase base Animal con una subclase Perro que requiere una edad no negativa en su constructor. El constructor de Perro recibe la edad y necesita validarla antes de pasarla al constructor de Animal.

Hasta ahora tendrías que usar un método auxiliar, algo así:

class Animal {
    int edad;
    public Animal(int edad) {
        this.edad = edad;
    }
}

class Perro extends Animal {
    public Perro(int edad) {
        super(verificarEdad(edad)); // Llamada a método auxiliar para validación
    }

    private static int verificarEdad(int edad) {
        if (edad < 0) {
            throw new IllegalArgumentException("La edad no puede ser negativa");
        }
        return edad;
    }

    public void ladrar() {
        System.out.println("¡Guau!");
    }
}

public class Main {
    public static void main(String[] args) {
        Perro miPerro = new Perro(5);
        miPerro.ladrar();

        try {
            Perro perroNegativo = new Perro(-2); // La excepción se lanza en verificarEdad
        } catch (IllegalArgumentException e) {
            System.err.println(e.getMessage());
        }
    }
}

En este caso, la lógica de validación (verificarEdad) está separada del constructor, lo que puede hacer que el código sea menos intuitivo.

Con el JEP 492, puedes incluir la lógica de validación directamente en el cuerpo del constructor antes de la llamada a super(...):

class Animal {
    int edad;
    public Animal(int edad) {
        this.edad = edad;
    }
}

class Perro extends Animal {
    public Perro(int edad) {
        if (edad < 0) {
            throw new IllegalArgumentException("La edad no puede ser negativa");
        }
        super(edad); // La validación ocurre directamente antes de la llamada a super
    }

    public void ladrar() {
        System.out.println("¡Guau!");
    }
}

public class Main {
    public static void main(String[] args) {
        Perro miPerro = new Perro(5);
        miPerro.ladrar();

        try {
            Perro perroNegativo = new Perro(-2); // La excepción se lanza directamente en el constructor
        } catch (IllegalArgumentException e) {
            System.err.println(e.getMessage());
        }
    }
}

Con esto simplificamos la escritura de constructores, especialmente en escenarios de herencia donde se necesita lógica antes de la llamada al constructor de la superclase, lo que resulta en un código más limpio y fácil de mantener. Es una característica que salió en preview en Java 22 y que ahora entra en su tercera iteración sin cambios, camino de ser definitiva.

Otros añadidos al lenguaje Java

• Declaraciones de importación de módulos: JEP 494, Module Import Declarations (Second Preview), introduce la capacidad de importar concisamente todos los paquetes exportados por un módulo. Esto simplifica la reutilización de bibliotecas modulares sin requerir que el código importador esté en un módulo en sí mismo.
• Archivos fuente simples y métodos main de instancia: JEP 495, Simple Source Files and Instance Main Methods (Fourth Preview), evoluciona el lenguaje Java para que los principiantes puedan escribir sus primeros programas sin necesidad de comprender características diseñadas para programas grandes. Permite declaraciones simplificadas para programas de una sola clase y métodos main que no necesitan ser public static void, facilitando una transición gradual hacia conceptos más avanzados. En archivos fuente simples, se importan automáticamente métodos útiles para la interacción con la consola (println, print, readln) y todas las clases e interfaces públicas de los paquetes exportados por el módulo java.base.

Gracias a esto último podemos pasar del clásico:

public class HolaMundo {
    public static void main(String[] args) {
        System.out.println("¡Hola, Mundo!");
    }
}

a un simple:

void main() {
    println("¡Hola, Mundo!");
}

A ver cuando pasan estas cosas a la versión definitiva.

Defensa contra el futuro: criptografía cuántica y seguridad mejorada en Java 24

La seguridad es una prioridad fundamental en JDK 24, con la incorporación de mecanismos para hacer frente a las amenazas emergentes, incluyendo los potenciales peligros de ruptura de criptografía por parte de la computación cuántica.

• Algoritmos de encapsulamiento de claves y firma digital cuántico-resistentes: el JDK 24 incluye implementaciones experimentales de algoritmos criptográficos diseñados para resistir ataques de futuros ordenadores cuánticos:

  • JEP 496, Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM): se trata de una API para ML-KEM, un mecanismo de encapsulamiento de claves estandarizado por NIST (FIPS 203) para asegurar claves simétricas a través de canales inseguros utilizando criptografía de clave pública resistente a ataques cuánticos. Se proporcionan implementaciones de KeyPairGenerator, KEM y KeyFactory para los conjuntos de parámetros ML-KEM-512, ML-KEM-768 y ML-KEM-1024.
  • JEP 497, Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA): proporciona una implementación de ML-DSA, otro algoritmo de firma digital estandarizado por NIST (FIPS 204) diseñado para detectar modificaciones no autorizadas en los datos y autenticar la identidad de los firmantes, siendo también resistente a ataques cuánticos. Se incluyen implementaciones de KeyPairGenerator, Signature y KeyFactory para los conjuntos de parámetros ML-DSA-44, ML-DSA-65 y ML-DSA-87. Es importante notar que el soporte para estos algoritmos en componentes de la plataforma como TLS o la firma de JARs podría añadirse en futuras versiones una vez que existan estándares definidos.

• API para funciones de derivación de claves (KDF): JEP 478, Key Derivation Function API (Preview), introduce una API para Funciones de Derivación de Claves (KDFs), algoritmos criptográficos para derivar claves adicionales a partir de una clave secreta y otros datos. Esta API en vista previa permite a las aplicaciones utilizar algoritmos KDF como HKDF (RFC 5869) y preparar el terreno para la futura implementación de Argon2.

• Preparación para restringir el uso de JNI: JEP 472, Prepare to Restrict the Use of JNI, emite advertencias sobre el uso de la Interfaz Nativa de Java (JNI) y ajusta la API de Funciones y Memoria Externas (FFM) para emitir advertencias de manera consistente. El objetivo es preparar a los desarrolladores para una futura versión que restrinja el uso de JNI y la FFM API por defecto, mejorando la integridad de la plataforma. Los desarrolladores podrán habilitar selectivamente estas interfaces donde sea esencial. Si todavía usas JNI, mucho cuidado y vete viendo esto.

• Security Manager deshabilitado permanentemente: JEP 486, Permanently Disable the Security Manager, avanza en la eliminación del Security Manager, que ya fue declarado obsoleto para su eliminación en Java 17. En JDK 24, se revisa la especificación de la Plataforma Java para que los desarrolladores no puedan habilitarlo y otras clases de la Plataforma no se refieran a él. La API del Security Manager se mantendrá en esta versión para dar tiempo a los desarrolladores a migrar, pero se eliminará en una versión futura. Más avisado no puedes estar...

• Advertencia sobre el uso de métodos de acceso a memoria en sun.misc.Unsafe: JEP 498, Warn upon Use of Memory-Access Methods in sun.misc.Unsafe, emite una advertencia en tiempo de ejecución la primera vez que se invoca cualquier método de acceso a memoria en sun.misc.Unsafe. Estos métodos, que fueron declarados obsoletos para su eliminación en el anterior JDK 23, han sido reemplazados por APIs estándar como la VarHandle API y la Foreign Function & Memory API.

• Soporte para incluir archivos de propiedades de seguridad: el archivo java.security ahora soporta la inclusión de otros archivos de propiedades mediante la directiva include <path-to-a-file>.

• Mejoras en SunPKCS11: el proveedor SunPKCS11 (Public-Key Cryptography Standards) se mejora para utilizar el mecanismo CKM_AES_CTS si la biblioteca PKCS#11 nativa lo soporta.

Nuevas APIs y mejoras en las librerías de Java 24

El JDK 24 añade nuevas APIs y mejora las existentes para ampliar las capacidades de la plataforma.

• Class-File API: JEP 484, Class-File API, proporciona una API estándar para analizar, generar y transformar archivos de clase Java. Tradicionalmente, para analizar o modificar archivos .class de Java, los desarrolladores recurrían a bibliotecas de terceros como ASM, BCEL o Javassist. Estas bibliotecas, aunque potentes, requerían que los desarrolladores aprendieran sus API específicas y era complicado mantenerse al día con las rápidas evoluciones del formato del archivo .class en cada nueva versión de JDK. Esto podía llevar a problemas de incompatibilidad si una biblioteca no se actualizaba rápidamente para soportar las nuevas características del formato. Con esta nueva API esto se acabó.
• Stream Gatherers: JEP 485, Stream Gatherers, mejora la Stream API para soportar operaciones intermedias personalizadas, permitiendo transformaciones de datos más complejas en las canalizaciones de streams.
• Valores con ámbito: JEP 487, Scoped Values (Fourth Preview), introduce los scoped values, que permiten compartir datos inmutables entre métodos dentro de un hilo y con hilos hijo de manera más sencilla y eficiente que las variables ThreadLocal, especialmente en combinación con hilos virtuales y concurrencia estructurada. Se ha eliminado la necesidad de métodos callWhere() y runWhere(), dejando la API más fluida.
• API de vectores: JEP 489, Vector API (Ninth Incubator), continúa su proceso de incubación añadiendo nuevas operaciones entre carriles (selectFrom y rearrange ahora envuelven índices en lugar de verificarlos), implementaciones intrínsecas para operaciones trascendentales y trigonométricas en ARM y RISC-V (a través de SLEEF), la nueva clase basada en valor Float16 para representar números de coma flotante de 16 bits, y nuevas operaciones aritméticas integrales.
• Nuevo Método Process.waitFor(Duration): se añade un nuevo método sobrecargado a la clase java.lang.Process que utiliza java.time.Duration para especificar el tiempo de espera, evitando confusiones con las unidades de tiempo.
• Nuevo Método Reader.of(CharSequence): se introduce el método fábrica estático java.io.Reader.of(CharSequence) para obtener un Reader que lee caracteres de un CharSequence, siendo más eficiente en algunos casos que java.io.StringReader.
• Soporte para Unicode 16.0: esta versión actualiza la versión de Unicode a 16.0, incluyendo nuevas escrituras y caracteres.
• Nuevas Opciones para la Herramienta jar: la herramienta jar se mejora con opciones para especificar el directorio de extracción (--dir o -C) y para no sobrescribir archivos existentes (--keep-old-files o -k).
• Nuevo MXBean para monitorizar y gestionar el planificador de hilos virtuales: se añade la interfaz jdk.management.VirtualThreadSchedulerMXBean para permitir la monitorización y gestión del planificador de hilos virtuales mediante JMX.
• Nuevos Comandos jcmd: se incorporan los comandos Thread.vthread_scheduler y Thread.vthread_pollers a la herramienta jcmd para ayudar a diagnosticar problemas con los hilos virtuales.

Herramientas para el desarrollador

En el JDK 24 se incluyen actualizaciones y mejoras en las herramientas de desarrollo del propio JDK:

• jpackage soporta WiX Toolset v4 y v5 en Windows: la herramienta jpackage ahora puede utilizar las versiones 4 y 5 de WiX Toolset en Windows, para crear paquetes de instalación en este sistema, además de la versión 3 que ya soportaba.
• Nuevo resumen de especificaciones externas en javadoc: la documentación de la API contiene una nueva página de resumen que lista las especificaciones externas referenciadas por las APIs de Java SE y JDK.

Cambios y eliminaciones importantes en Java 24

El JDK 24 también trae consigo la eliminación y obsolescencia de algunas características y opciones.

• Eliminación de opciones de línea de comandos de java: las opciones -t, -tm, -Xfuture, -checksource, -cs y -noasyncgc ya no son aceptadas por el comando java.
• Obsolescencia de ciertas opciones de línea de comandos de java: las opciones -verbosegc, -noclassgc, -verify, -verifyremote, -ss, -ms y -mx del comando java están obsoletas para su eliminación. Se sugieren opciones de reemplazo para algunas de ellas.
• Eliminación del Soporte para GTK2 en Linux Desktop: se ha eliminado el soporte para la versión 2 de la biblioteca GTK en el módulo java.desktop.
• Eliminación del comportamiento compatible con JDK 1.1 para las zonas horarias "EST", "MST" y "HST": se elimina el comportamiento compatible con JDK 1.1 para estas zonas horarias, y la propiedad del sistema sun.timezone.ids.oldmapping ya no está operativa. Se recomienda utilizar los IDs de zona horaria basados en regiones.
• Eliminación de la propiedad de entorno JNDI java.naming.rmi.security.manager y la Constante javax.naming.Context.APPLET: estas características relacionadas con el Security Manager, que está en proceso de eliminación, ya no están soportadas.
• Deshabilitación permanente de la descarga remota de código JNDI: se deshabilita permanentemente la descarga remota de código para los proveedores LDAP y RMI de JNDI.
• Eliminación de la lógica de compatibilidad serialVersionUID de JMX: se elimina la lógica de compatibilidad para versiones muy antiguas de JMX.
• Obsolescencia de java.util.zip.ZipError para su futura eliminación: esta clase de error ha quedado obsoleta y se recomienda utilizar java.util.zip.ZipException en su lugar.
• Obsolescencia de la herramienta jstatd para su eliminación futura: la herramienta jstatd, un servidor RMI para monitorizar HotSpot VMs, está obsoleta para su eliminación en una futura versión.
• Obsolescencia del flag LockingMode y los modos LM_LEGACY y LM_MONITOR: estos elementos relacionados con el mecanismo de bloqueo de objetos monitor están obsoletos, ya que el modo LM_LIGHTWEIGHT será la única implementación soportada en el futuro.
• Obsolescencia de jhsdb debugd para su próxima eliminación: el subcomando debugd de la herramienta jhsdb está marcado como obsoleto.
• Obsolescencia del port de 32-bit x86 para su eliminación: se declara obsoleto el soporte para la arquitectura de 32-bit x86 en todas las plataformas, con la intención de eliminarlo en una versión futura.
• Obsolescencia de la herramienta jrunscript para su eliminación: la herramienta jrunscript está obsoleta y será eliminada en una futura versión.

En resumen

Java 24 continúa la evolución de la plataforma, con una serie de novedades centradas en la mejora del rendimiento, especialmente en el tiempo de inicio de las aplicaciones gracias a la carga y enlazado de clases anticipado. También se ha hecho un énfasis significativo en la seguridad, con la introducción de algoritmos criptográficos resistentes a ataques cuánticos y la preparación para restringir el uso de interfaces nativas.

Además, esta versión trae consigo nuevas herramientas y APIs para facilitar el desarrollo, como la manipulación de archivos de clase y operaciones intermedias personalizadas en Streams. Se mantienen los esfuerzos por modernizar el lenguaje y la plataforma, eliminando componentes obsoletos como el Security Manager y preparando la eliminación de otros.

Finalmente, Java 24 sigue invirtiendo en mejorar la concurrencia y la escalabilidad, con avances en la sincronización de hilos virtuales y la expansión tardía de barreras en el recolector de basura G1.

En definitiva, esta versión se presenta como una sólida actualización que sienta las bases para futuras optimizaciones y nuevas capacidades.

Es un tanto complicado de resumir todo, pero esperamos que esta vista rápida a las novedades, convenientemente agrupadas y con enlaces para conocer más detalles, te ayuden a mantenerte al día con la plataforma Java.

Y si estás aprendiendo, no te olvides de que con nosotros puedes aprender BIEN, a tu ritmo y de la mano de un reconocido experto: Desarrollo de aplicaciones con la plataforma Java.