¿Deberías adoptar Java 26? Ventajas y precauciones explicadas para el día a día

Java 26 alcanzó disponibilidad general el 17/03/2026.

Hay muchas funcionalidades en vista previa de nuevo, pero hay algunos cambios en HTTP/3, G1 GC y hilos virtuales que podrían marcar una diferencia real de forma silenciosa.

Por otro lado, si tu entorno todavía arrastra APIs heredadas o flags antiguos de JVM, hay puntos claros donde una actualización podría causarte problemas.

Especialmente viniendo desde Java 8, la brecha es lo suficientemente grande como para que sea mejor identificar dónde te vas a atascar antes de mirar las novedades de Java 26.

Diagrama general

Java 8 in production
	|
	+-- Audit legacy APIs / libraries
	|      - javax.xml.bind
	|      - Thread.stop
	|      - sun.*
	|      - Old JVM flags
	|
	+-- Validate on an LTS first
	|      - Test on Java 17 or 21
	|
	+-- Then check Java 26 deltas
			 - HTTP/3
			 - G1 improvements
			 - Virtual thread changes
			 - Security default changes

Lo que pinta bien

java.net.http.HttpClient ahora soporta HTTP/3.

Poder usar HTTP/3 sin cambios importantes en el código del lado de la aplicación es directamente útil.

Más allá de eso, hay mejoras de rendimiento bastante sólidas: reducción de sincronización en G1 GC, mejor recuperación de objetos enormes, y AOT Object Cache ahora soporta cualquier GC.

Los hilos virtuales también se han mejorado — es menos probable que retengan el hilo portador mientras esperan la inicialización de clases, lo que debería reducir escenarios de bloqueo extraños.

Algunas adiciones menores pero bienvenidas:

• Process ahora implementa AutoCloseable
• Se añadió UUID.ofEpochMillis(), facilitando el manejo al estilo UUIDv7
• ByteOrder ahora es un enum, lo que facilita su uso en sentencias switch

Por ejemplo, el HTTP Client te permite beneficiarte con cambios mínimos en el código:

var client = HttpClient.newBuilder()
	.version(HttpClient.Version.HTTP_3)
	.build();

var request = HttpRequest.newBuilder()
	.uri(URI.create("https://example.com/api/status"))
	.GET()
	.build();

var response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());

Y dado que Process ahora implementa AutoCloseable, la limpieza después de ejecutar comandos externos es un poco más limpia:

try (var process = new ProcessBuilder("java", "-version").start()) {
	var exitCode = process.waitFor();
	System.out.println("exit=" + exitCode);
}

Cosas a tener en cuenta

Primero, Thread.stop() ha sido eliminado.

Si todavía persiste en código de mantenimiento heredado, directamente no compilará en JDK 26.

La API de Applet también ha sido eliminada, así que los entornos que utilizan documentación o ejemplos antiguos deben tener cuidado.

La limpieza de flags de JVM también ha avanzado — flags como -Xmaxjitcodesize, MaxRAM y AggressiveHeap que has estado usando por inercia pueden necesitar revisión.

RMI sobre TLS ahora impone la identificación de endpoints por defecto, por lo que los entornos con SANs de certificados descuidados pueden encontrar fallos de conexión.

HttpRequest.Builder.timeout() ahora cubre la recepción completa del cuerpo de la respuesta, no solo la conexión inicial. Dependiendo de tu diseño de timeout existente, esto podría causar diferencias de comportamiento notables.

Para los entornos que han estado ejecutándose en Java 8 durante mucho tiempo, esto es lo que debes tener en cuenta antes de saltar directamente a Java 26:

• Java 8 se ejecutaba bajo el modelo classpath, pero a partir de Java 9, los límites de módulos y las dependencias de APIs internas se hacen visibles
• Los módulos de Java EE / CORBA fueron eliminados en Java 11, así que si javax.xml.bind todavía está en tu código, necesitarás una corrección por separado
• Los valores por defecto de reflexión y seguridad se han vuelto más estrictos — código que antes funcionaba silenciosamente ahora puede generar advertencias o fallar
• Las configuraciones antiguas de TLS, almacenes de claves y conexiones RMI son propensas a romperse justo después de una actualización

Para los sistemas empresariales japoneses, la codificación de caracteres es también un campo minado silencioso.

Los sistemas bancarios y de negocio core en particular a menudo todavía asumen codificaciones de la familia Shift_JIS para las integraciones de back-office y sistemas host.

Si consolidas todo de forma ingenua diciendo «UTF-8 es el estándar ahora», puedes terminar con bugs insidiosos donde la interfaz funciona bien pero los informes o las integraciones externas producen texto ilegible.

En la era de Java 8, había mucho código que funcionaba casualmente porque el charset por defecto en Windows era windows-31j.

Pero desde JDK 18, el charset por defecto es UTF-8, por lo que patrones como new String(bytes) o FileReader que dependen del charset implícito se comportarán de manera diferente después de la migración.

En la práctica, tampoco deberías tratar Shift_JIS y windows-31j como intercambiables.
Ambos están disponibles en la lista de charsets de Java, pero windows-31j / MS932 incluye extensiones específicas de Windows, por lo que puede haber discrepancias con números encerrados en círculos, caracteres dependientes de plataforma y extensiones IBM/NEC.

Para transferencias de archivos bancarios y conexiones con sistemas host, es más seguro confirmar de antemano si la otra parte espera «Shift_JIS pero en realidad CP932», «estrictamente dentro del rango Shift_JIS», o «incluyendo páginas de código de host IBM».

Si estás analizando específicamente problemas con el idioma japonés, estos deberían ser parte de tu lista de verificación previa a la migración:

• ¿Se especifica explícitamente el charset en las conversiones de arrays de bytes?
• ¿Estás confundiendo Shift_JIS con windows-31j?
• ¿Has verificado la corrección de ida y vuelta para números encerrados en círculos, wave dash, tilde de ancho completo, caracteres dependientes de plataforma y gaiji?
• Para CSVs de informes, archivos de longitud fija y transmisiones a host: ¿estás confundiendo longitudes basadas en caracteres con longitudes basadas en bytes?
• ¿Puedes detectar caracteres no mapeables en lugar de reemplazarlos silenciosamente?

Así que si vienes de Java 8, en lugar de saltar directamente a 26 en producción, es más realista primero conseguir que tu compilación y tests pasen en LTS 17 o 21, eliminar las dependencias antiguas allí, y después evaluar Java 26.

Java 26 en sí es interesante, pero absorber el delta desde Java 8 es donde reside la mayor parte del trabajo real en la práctica.

Qué verificar antes de actualizar

El primer paso más rápido es hacer un escaneo general de APIs y flags obsoletos.

grep -R "Thread\.stop\|Xmaxjitcodesize\|AggressiveHeap\|MaxRAM" ./

Si quieres detectar también dependencias de la era de Java 8, ejecuta esto:

grep -R "javax\.xml\.bind\|javax\.activation\|CORBA\|sun\." ./

Para hacer un escaneo general de suposiciones de charset, esto ayuda a detectar cosas que podrías pasar por alto:

grep -R "Shift_JIS\|MS932\|windows-31j\|Cp943\|Cp930\|EBCDIC\|file.encoding" ./

En el lado de Java, es más seguro especificar explícitamente los charsets y detectar caracteres no mapeables en lugar de depender del charset por defecto:

var charset = Charset.forName("windows-31j");
var encoder = charset.newEncoder()
	.onMalformedInput(CodingErrorAction.REPORT)
	.onUnmappableCharacter(CodingErrorAction.REPORT);

var bytes = encoder.encode(CharBuffer.wrap("顧客コード①"));
System.out.println(bytes.remaining());

Una comparación aproximada:

• Java 26 desde la perspectiva de Java 8: Brecha grande — esto es un proyecto de migración
• Java 26 desde la perspectiva de Java 17: Principalmente evaluar nuevas funcionalidades y verificar cambios en valores por defecto
• Java 26 desde la perspectiva de Java 21: El coste de migración es relativamente ligero

En términos más prácticos:

Para proyectos en Java 8, antes de entusiasmarse con las nuevas funcionalidades de Java 26, el tema real suele ser descubrir cómo despegar la deuda técnica de la era de Java 8.

Por el contrario, si ya estás en Java 17 o 21, Java 26 no es una «migración completa» — se trata más de evaluar cómo incorporar mejoras de rendimiento y cambios en valores por defecto.

Aquí hay algunas cosas que vale la pena verificar en CI para mayor tranquilidad:

• Comportamiento de timeout y headers de HttpClient
• Comunicación RMI / TLS que involucre validación de certificados
• Creación de runtime con jlink
• Dependencias de XML Signature y almacenes de claves heredados
• Tests de ida y vuelta para archivos de integración con Shift_JIS / windows-31j / host

Las funcionalidades en vista previa / incubadora son interesantes, pero probablemente sea mejor considerarlas como objetivos de evaluación en lugar de listas para producción en este momento.

Resumen

Java 26 no es tanto un único gran cambio revolucionario como una acumulación de mejoras sólidas en rendimiento, APIs estándar y valores por defecto operativamente más seguros.

Para los sistemas empresariales típicos, las mejoras en HTTP/3, GC e hilos virtuales son avances positivos.

Por otro lado, cuanto más código heredado y flags de runtime antiguos tenga tu entorno, más importante es auditar primero y actualizar después.

Para los entornos japoneses, la codificación de caracteres en particular no debería posponerse.

En los entornos donde las codificaciones de la familia Shift_JIS o las integraciones con sistemas host todavía están en uso, corregir las dependencias del charset por defecto y los problemas de ida y vuelta del japonés tiene prioridad sobre evaluar las nuevas funcionalidades de Java 26.

Especialmente viniendo desde Java 8, hacer una limpieza intermedia en LTS 17 o 21 primero y después ir a por los beneficios de Java 26 es el camino más sensato.