Cuando IBM lanzó Suite de aplicaciones Maximo (MAS) 9.1 en junio de 2025, la mayoría de los titulares fueron a Asistentes impulsados por IA, mejoras en las aplicaciones móviles y capacidades de integración ampliadas. Sin embargo, hay un cambio que destaca entre los equipos de TI y operaciones: el cambio de Java 11 a Java 17.
‍

A primera vista, esto puede parecer una actualización rutinaria del tiempo de ejecución. En realidad, cambia los parámetros de seguridad, modifica el comportamiento del rendimiento e introduce consideraciones de compatibilidad que pueden afectar a todo, desde los scripts personalizados hasta las integraciones empresariales. Si la trata como una actualización silenciosa, corre el riesgo de recibir sorpresas desagradables en la producción.

Por qué es importante Java 17

Java 17 es una versión de soporte a largo plazo (LTS), lo que significa estabilidad al menos hasta 2029. Esta es una buena noticia para los administradores que desean menos actualizaciones forzadas y un ciclo de vida más predecible. También se alinea con la hoja de ruta MAS de IBM, lo que garantiza que las futuras mejoras, especialmente las relacionadas con la IA y la implementación nativa de la nube, sean totalmente compatibles con su entorno.
‍

Más allá de las ventajas del ciclo de vida, Java 17 ofrece:

• Seguridad mejorada con una configuración TLS predeterminada más sólida y la eliminación de algoritmos criptográficos obsoletos.

• Mejoras en el rendimiento mediante un inicio más rápido, un manejo más eficiente de la memoria y el recolector de basura G1 como predeterminado.

• Compatibilidad con el desarrollo moderno por lo que los nuevos módulos y extensiones de MAS pueden ejecutarse sin depender de API anticuadas.
  ‍

No se trata de algo «práctico», sino que es fundamental para mantener su instancia de MAS segura, eficiente y lista para lo que viene.

Qué podría romperse

No todos los cambios son positivos. Java 17 aplica reglas más estrictas y elimina las funciones heredadas de las que aún dependen algunos entornos. Por ejemplo, si tiene clases de MBO personalizadas o scripts de automatización que llaman a las API obsoletas, es posible que esos métodos ahora hayan desaparecido por completo. Del mismo modo, las integraciones de terceros basadas en controladores JDBC o clientes SOAP antiguos pueden fallar con los estrictos valores predeterminados de seguridad de Java 17.
‍

También puede encontrar:

• Indicadores de JVM no compatibles (por ejemplo, UseConcmarkSweepGC) que simplemente no se reconocerán.

• Extensiones de interfaz de usuario basadas en reflexiones ese intento de acceder a las clases internas de Java, ahora bloqueadas de forma predeterminada.
  ‍
  

En última instancia, si no identificas estas dependencias antes de la actualización, podrían aparecer como errores en la producción, a veces solo bajo carga.

Preparación para la actualización

Aborde esta transición como lo haría con cualquier cambio estratégico, combinando la planificación, las pruebas y la implementación por etapas. Comience por auditar su entorno MAS y documentar cada personalización, integración y dependencia. Una vez que sepa lo que está en juego, cree una instancia de MAS 9.1 en modo sandbox con Java 17 y ejecútela como si estuviera activa: pruebe las órdenes de trabajo, la generación de informes, la sincronización móvil y las integraciones con cargas de trabajo reales.
‍

Dentro de este proceso:

• Actualización Controladores, bibliotecas y conectores JDBC para versiones compatibles con Java 17.

• Reemplazar indicadores de JVM obsoletos con equivalentes compatibles.

• Revisar sus políticas de java.security para confirmar la transferencia de la configuración de cifrado.
  ‍
  

Y, por último, planifique la interrupción de la producción durante las horas de bajo impacto, con una ruta de retroceso y un plan claro de comunicación con las partes interesadas.

Verificación posterior a la actualización

Una vez que te hayas cambiado, la vigilancia es importante. Supervise los registros de su sistema para detectar errores de clases no encontradas, discordancias entre métodos o errores de protocolo SSL. Compare las métricas de la CPU, la memoria y las transacciones con las bases de referencia anteriores a la actualización para detectar regresiones sutiles en el rendimiento. Y lo que es más importante, mantenga abiertos los canales de retroalimentación con los equipos de operaciones, ya que con frecuencia serán los primeros en detectar las anomalías funcionales.
‍

Un buen período de revisión posterior a la actualización también debería reflejar cualquier «lección aprendida» para que el próximo cambio importante en el tiempo de ejecución o la versión de MAS sea más fluido.

Conclusiones clave

La migración de Java 17 en MAS 9.1 es un cambio de nivel básico, no solo una actualización en segundo plano. Al combinar un inventario exhaustivo, pruebas específicas y una implementación cuidadosa, puede evitar interrupciones y, al mismo tiempo, obtener los beneficios de seguridad y rendimiento que IBM diseñó en esta versión.