Oracle publicó Java 27 el 15 de septiembre de 2026. La nueva versión incorpora mejoras en el funcionamiento de la máquina virtual, herramientas de diagnóstico y seguridad, además de continuar la evolución de distintas funcionalidades del lenguaje. Sin embargo, su llegada no significa que todas las empresas deban actualizar inmediatamente sus aplicaciones.
Para los equipos que mantienen servicios, integraciones y aplicaciones de negocio, la pregunta no es únicamente qué novedades ofrece Java 27. También deben valorar qué versión encaja con sus necesidades, qué compatibilidad tiene su ecosistema y cómo realizar una transición sin comprometer la operación.
La decisión exige combinar tecnología, mantenimiento y preparación del equipo. Una actualización bien planificada no consiste solo en sustituir el JDK: implica comprobar dependencias, validar el comportamiento de las aplicaciones y establecer criterios compartidos entre desarrollo y operaciones.
Java 27 y Java 25 LTS: dos opciones con horizontes diferentes
Antes de evaluar una migración, conviene distinguir entre la versión más reciente y una versión con soporte a largo plazo.
Según la información de Oracle, Java 27 es la versión más reciente de Java SE, mientras que Java 25 es la última versión LTS —Long-Term Support—. Java 21 es la LTS anterior. Por tanto, «última versión» y «última LTS» no son expresiones equivalentes.
Java 27 permite acceder a las incorporaciones más recientes de la plataforma, pero obliga a considerar un horizonte de actualización más cercano. Oracle indica que su JDK 27 recibirá actualizaciones bajo las condiciones NFTC hasta marzo de 2027, cuando será sustituido por JDK 28. Para Oracle JDK 25, ese periodo se extiende hasta septiembre de 2028. Estos plazos describen las condiciones de actualización de esa distribución concreta, no las de todos los proveedores de Java.
La elección debería partir de las características de cada aplicación:
- Un servicio crítico puede priorizar un ciclo de mantenimiento estable y compatibilidad acreditada.
- Un proyecto nuevo puede tener más margen para evaluar funcionalidades recientes.
- Un equipo con pruebas automatizadas y despliegues frecuentes puede asumir actualizaciones con mayor regularidad.
- Una aplicación antigua puede necesitar primero revisar dependencias y herramientas, antes de decidir el JDK de destino.
No se trata de elegir siempre la versión con el número más alto, sino una plataforma que la organización pueda mantener con garantías.
Qué novedades de Java 27 interesan a los equipos empresariales
Java 27 incluye nueve propuestas de mejora del JDK, conocidas como JEP —JDK Enhancement Proposals—. Para una empresa, interesa distinguir qué cambios afectan al funcionamiento de las aplicaciones existentes y cuáles requieren decisiones explícitas de desarrollo.
Cambios en el uso de memoria y la recolección de basura
Entre las novedades anunciadas figuran la activación por defecto de las cabeceras compactas de objetos y el uso de G1 como recolector de basura predeterminado en todos los entornos. Las primeras buscan reducir la sobrecarga de memoria asociada a los objetos; el segundo cambio pretende ofrecer un comportamiento operativo más consistente entre entornos.
Estos avances pueden resultar relevantes para organizaciones que ejecutan numerosos servicios Java o aplicaciones con una elevada creación de objetos. Sin embargo, una mejora de la plataforma no permite prometer automáticamente un porcentaje de ahorro o un aumento de rendimiento en cualquier aplicación.
La evaluación debe realizarse con cargas representativas. El equipo debería comparar consumo de memoria, uso de CPU, tiempos de respuesta y comportamiento de la recolección de basura antes de convertir una expectativa en una decisión de infraestructura.
Diagnóstico con mayor atención a los datos sensibles
Java 27 incorpora una mejora para redactar datos dentro del propio proceso en Java Flight Recorder —JFR—. Su objetivo es reducir la exposición de información sensible en los registros de diagnóstico, manteniendo su utilidad para investigar problemas de producción.
La relevancia empresarial está en el equilibrio entre observabilidad y protección de datos. Capturar información técnica ayuda a resolver incidencias, pero el equipo también debe saber qué registra, quién puede acceder a esas capturas y cómo se conservan.
Esta novedad ofrece una oportunidad para revisar los procedimientos de diagnóstico, no solo las opciones de la máquina virtual.
Avances en comunicaciones seguras
El lanzamiento también introduce intercambio híbrido de claves poscuántico para TLS 1.3. Oracle lo presenta como un avance para proteger las comunicaciones frente a escenarios en los que un atacante captura información cifrada hoy con la intención de descifrarla en el futuro.
Esto no significa que una aplicación quede preparada frente a cualquier riesgo por ejecutar Java 27. Las comunicaciones dependen también de la configuración, los extremos de la conexión y los componentes de infraestructura que intervienen.
Para los equipos empresariales, el interés está en comprender la evolución de la plataforma y evaluar su encaje en los requisitos de seguridad de cada servicio.
Funcionalidades en preview e incubación
No todas las incorporaciones tienen el mismo grado de madurez. En Java 27, la concurrencia estructurada continúa en preview, al igual que los tipos primitivos en patrones y las constantes diferidas. La Vector API permanece en incubación.
La distinción es importante: una funcionalidad disponible para experimentar no debe confundirse con una API definitiva sobre la que construir una dependencia de largo plazo.
Una política interna debería establecer cuándo se permite utilizar estas funcionalidades, en qué proyectos y quién asume la revisión de posibles cambios posteriores.
Qué revisar antes de cambiar el JDK
La migración afecta a más componentes que el código de la aplicación. Para planificarla, resulta útil separar la revisión en cuatro ámbitos.
1. Inventario de aplicaciones y entornos
El primer paso es identificar qué se ejecuta realmente en la organización.
Conviene registrar:
- Versión y distribución del JDK.
- Sistemas operativos y arquitecturas.
- Aplicaciones y servicios que dependen de cada instalación.
- Imágenes de contenedor utilizadas.
- Parámetros de ejecución de la JVM.
- Responsables de mantenimiento y criticidad de cada servicio.
Este inventario evita planificar la migración a partir de información parcial o descubrir demasiado tarde que desarrollo y producción utilizan configuraciones diferentes.
2. Dependencias, frameworks y herramientas
Después hay que comprobar si el conjunto de herramientas admite la versión de destino: frameworks, bibliotecas, servidores de aplicaciones, controladores de bases de datos y herramientas de construcción.
La revisión también debe incluir componentes menos visibles, como agentes de monitorización, instrumentación, generación de código o procesadores de anotaciones.
En lugar de asumir que todo será compatible porque la aplicación es Java, conviene consultar la documentación de cada proveedor y probar la combinación concreta que utiliza la empresa.
3. Compilación y comportamiento en ejecución
Cambiar el JDK que ejecuta una aplicación, cambiar el que la compila y adoptar nuevas funcionalidades del lenguaje son decisiones relacionadas, pero distintas.
Por eso, una migración puede organizarse en etapas:
- Preparar un entorno con el JDK de destino.
- Comprobar la construcción y ejecución de la aplicación.
- Resolver incompatibilidades y actualizar dependencias cuando sea necesario.
- Validar el comportamiento funcional y operativo.
- Evaluar después cambios en el código para aprovechar nuevas capacidades.
Separar estas fases facilita identificar el origen de los problemas y evita mezclar una actualización de plataforma con una reescritura innecesaria.
4. Distribución, licencia y mantenimiento
La planificación debe incluir la distribución elegida y sus condiciones de uso. No basta con anotar «Java 27» en un documento técnico.
Oracle publica sus condiciones para Oracle JDK y distingue periodos y licencias según la versión. Por ejemplo, su página de descargas indica que las actualizaciones de Oracle JDK 21 posteriores al periodo NFTC pasan a regirse por la licencia OTN, cuyo uso en producción puede requerir pago fuera de las concesiones gratuitas previstas. Esta información no debe extrapolarse a todas las distribuciones de OpenJDK.
La organización debería revisar por separado compatibilidad técnica, acceso a actualizaciones, soporte y condiciones de licencia, con los responsables correspondientes.
Cómo validar una migración sin depender únicamente de las pruebas funcionales
Una aplicación puede superar sus pruebas funcionales y presentar un comportamiento diferente bajo carga. Por ello, la validación debería incluir tanto resultados de negocio como indicadores operativos.
Entre las comprobaciones recomendables están:
- Operaciones críticas e integraciones externas.
- Tiempos de respuesta y tasa de errores.
- Consumo de memoria y CPU.
- Tiempo de arranque y preparación del servicio.
- Comportamiento bajo carga sostenida.
- Procesos programados y tareas por lotes.
- Registros, métricas y herramientas de diagnóstico.
Las comparaciones necesitan condiciones similares: misma carga, recursos equivalentes y configuración documentada. De lo contrario, resulta difícil atribuir una diferencia al cambio de JDK.
También debe prepararse una estrategia de despliegue y recuperación. Volver al entorno anterior exige conservar artefactos y configuraciones conocidos y evitar cambios simultáneos que hagan incompatible esa vuelta atrás.
Un ejemplo: modernizar una aplicación sin cambiarlo todo a la vez
Imaginemos una empresa que mantiene una aplicación Java para gestionar pedidos, con acceso a una base de datos y conexiones con servicios externos.
La publicación de Java 27 despierta interés por sus mejoras de memoria y diagnóstico. Sin embargo, el equipo no necesita elegir entre actualizar inmediatamente o seguir indefinidamente con su entorno actual.
Puede comenzar inventariando las dependencias y comprobando qué versiones admiten sus proveedores. Después, preparar una prueba con Java 25 LTS y otra con Java 27 para comparar compatibilidad y comportamiento, sin modificar todavía las reglas de negocio.
A partir de esos resultados, la decisión puede ser adoptar una LTS para producción y mantener un entorno de evaluación de la versión más reciente. También puede optar por Java 27 si existe una necesidad concreta y capacidad para seguir su ciclo de actualización.
El valor de este proceso está en decidir con evidencia propia. Las novedades del JDK son el punto de partida; los resultados de la aplicación y los requisitos del negocio determinan la elección.
Qué conocimientos necesita compartir el equipo TIC
Una migración no debería depender exclusivamente de la persona que mejor conoce la JVM.
Los desarrolladores necesitan comprender compatibilidad, dependencias, construcción y evolución del lenguaje. Los profesionales de sistemas y operaciones deben conocer configuración, recursos, observabilidad y despliegue. Los responsables técnicos necesitan criterios para elegir versiones, aceptar riesgos y organizar el mantenimiento.
La formación resulta especialmente útil cuando permite trabajar sobre preguntas concretas: qué hay que revisar, cómo interpretar una prueba de rendimiento o qué información debe recopilarse antes de una incidencia.
Para CLEFormación, la conexión con la formación in company está precisamente en ese reto compartido. Actualizar los conocimientos del equipo en Java debe ayudar a establecer un lenguaje común y procedimientos aplicables a los proyectos de la organización, no limitarse a presentar nuevas funcionalidades.
Java 27 como oportunidad para revisar la estrategia de mantenimiento
La llegada de Java 27 aporta nuevas capacidades y abre una oportunidad para revisar cómo se mantiene el software Java en la empresa. No obliga a migrar todos los sistemas, pero sí invita a comprobar si existe un inventario fiable, una política de versiones y un proceso de validación repetible.
La mejor decisión combina un JDK adecuado, dependencias compatibles y un equipo preparado para sostener el cambio. Antes de dar el salto, conviene identificar qué conocimientos faltan y qué tareas deben dominar los profesionales implicados.
En CLEFormación, la formación para equipos puede orientarse a ese objetivo: reforzar los conocimientos de Java y convertir la actualización tecnológica en un proceso planificado, verificable y compartido.