Cambiar el motor de Java en StrategyQuant X: GraalVM, Zulu y Temurin

Sustituir la máquina virtual de Java es la mejora gratuita más grande disponible en SQX. Cómo hacerlo, cuánto se gana y por qué hay comparativas que dicen lo contrario.

Es la única mejora que puede darte entre un 15 y un 25 % más de estrategias por hora sin tocar el hardware, y se hace renombrando una carpeta. También es la que más gente adopta por fe y no por medición.

SQX es una aplicación Java. El intérprete que la ejecuta viene incluido en el paquete, es estable y está probado, pero no tiene por qué ser el más eficiente para el tipo de carga que tú vas a ejecutar.

Sustituirlo lleva cinco minutos y se deshace en treinta segundos. Lo que no es opcional es medir antes y después, y ahora verás por qué.

Tabla de contenidos

Qué reportan los usuarios de SQX

El interés por GraalVM nace de un hilo del foro oficial que se ha vuelto referencia. Manteniendo exactamente la misma configuración, su autor documentó alrededor de un 15 % más de velocidad de generación y cerca de un 40 % menos de consumo de memoria, sin errores ni cierres. Otros participantes aportaron mediciones propias en la misma línea: cerca de un 25 % de mejora en una compilación posterior, y entre un 20 y un 25 % más de estrategias por hora sobre una base de Java 11.

El caso más elocuente no es de velocidad sino de memoria. Un usuario que trabajaba con diez mil estrategias en el databank sobre oro, de las configuraciones más exigentes que existen, pasó de saturar sus 64 GB con congelaciones ocasionales a ocupar unos 45 GB con el databank lleno. La ganancia ahí no es ir más rápido: es que el proceso deja de caerse.

El contraejemplo que conviene conocer

Existe una comparativa técnica independiente que enfrentó cuatro máquinas virtuales de Java a la vez, sometiéndolas simultáneamente a la misma carga: una aplicación web reactiva bajo pruebas de estrés. Los resultados fueron los contrarios.

En ese escenario GraalVM dio los peores tiempos de respuesta, alrededor de un 30 % por detrás, el mayor uso de CPU, un 25 % más de clases cargadas y las pausas más largas de recolección de basura. Zulu fue el que menos memoria consumió.

¿Se contradicen? No. Miden cargas distintas. Un compilador de este tipo necesita tiempo de calentamiento para optimizar el código que más se repite: un servicio que responde en milisegundos no le da ese margen, y una sesión de generación de doce horas se lo da de sobra. Por eso lo que funciona en SQX puede no funcionar en un servidor web y al revés.



CLAVE PRÁCTICA

Guarda esta idea para cualquier consejo de optimización que leas en cualquier ámbito: pregúntate en qué tipo de carga se midió. Un dato sin contexto es una anécdota.

Qué versión descargar

GraalVM se distribuye en dos líneas: la de Oracle, de uso libre en producción bajo sus términos gratuitos, y la Community Edition, de código abierto y sin soporte. Para nuestro caso ambas sirven; conviene elegir una versión de soporte prolongado y no la de última hornada.



ATENCIÓN

Antes de descargar nada, mira con qué versión de Java funciona tu instalación: abre una consola dentro de la subcarpeta `bin` del motor y ejecuta `java -version`. Saltar varias versiones de Java es la causa más frecuente de que SQX arranque mal o recompile sin parar.

Sobre el futuro de GraalVM hay una noticia que conviene tener presente si estás decidiendo a varios años vista. En septiembre de 2025 Oracle anunció que lo desengancha del ciclo de Java: la versión para JDK 24 fue la última licenciada y soportada dentro de sus productos Java SE, el compilador experimental deja de incluirse en el Oracle JDK y el equipo redirige el foco hacia los lenguajes no Java del ecosistema.

Se leyó con bastante alarmismo, y no toca. Lo que se retira es el soporte comercial dentro de las suscripciones; la tecnología sigue disponible tanto bajo los términos gratuitos como en la edición abierta. Puedes seguir usándola exactamente igual que antes. Lo que sí cambia es la lectura a largo plazo: con Oracle canalizando las mejoras hacia el propio JDK, la ventaja diferencial tenderá a estrecharse.

Los cuatro candidatos

Motor	A favor	Cuándo usarlo
El incluido en SQX	Probado y listo para usar, sin necesidad de configuración adicional.	Si prefieres no realizar cambios o si las alternativas presentan problemas.
GraalVM	Entre un 15 % y un 25 % más rápido y con hasta un 40 % menos de consumo de memoria, según diversos usuarios.	Primera opción para pruebas de generación intensiva y optimizaciones masivas.
Azul Zulu	Muy estable, eficiente en consumo de recursos y recomendado en la documentación oficial.	Si GraalVM genera problemas de estabilidad o compatibilidad.
Eclipse Temurin	Sucesor de AdoptOpenJDK, ampliamente utilizado y muy fiable.	Como alternativa de respaldo cuando Zulu no ofrece los resultados esperados.



ATENCIÓN

GraalVM no está soportado oficialmente por StrategyQuant. En algunas combinaciones provoca fallos de Java o errores al abrir los diálogos de archivos. Si aparece inestabilidad, vuelve atrás sin dramatismo y prueba Zulu.

El procedimiento

Según la versión, la carpeta del motor se llama `j` o `j64`. Confirma el nombre en tu instalación antes de empezar.

Cierra SQX por completo.
Entra en la carpeta de instalación y anota la versión actual con `java -version` desde `bin`.
Renombra la carpeta del motor a `j-old` o `j64-original`. Esa es tu marcha atrás.
Crea una carpeta nueva y vacía con el nombre exacto que tenía la original.
Descarga el motor alternativo en ZIP de 64 bits y descomprímelo.
Dentro hay una carpeta con el nombre de la distribución. Copia su contenido, no la carpeta.
La estructura final debe quedar `j/bin`, `j/lib`, `j/conf`. Si te queda `j/graalvm-xx/bin`, has copiado un nivel de más. Es el fallo número uno.
Recompilará los snippets y tardará más de lo normal en este primer arranque.
Ejecuta la medición y compara con tu línea base.



CLAVE PRÁCTICA

Conserva la carpeta original de forma permanente. Volver atrás es borrar la nueva y renombrar la vieja. No hay que reinstalar ni se pierde ninguna configuración.

Cómo decidir con tus datos

La comparación se hace con el protocolo de los diez minutos, que documentamos aparte. Repítelo con cada motor y anota generadas, estrategias por hora, aceptadas y pico de memoria. Dos mediciones por motor como mínimo: la primera ejecución tras cambiar de máquina virtual nunca es representativa.

Si un motor supera en más de un 15 % al incluido y aguanta estable una sesión larga, adóptalo.
Si la ventaja es marginal o hay inestabilidad, quédate con Zulu o con el de fábrica.
Si la diferencia entre los cuatro es menor del 5 %, no toques nada. El riesgo no compensa.
Si mejora la memoria aunque no la velocidad, también has ganado: podrás mantener databanks mayores.

Y una prueba final que mucha gente omite: antes de dar por bueno un motor, déjalo trabajar una sesión completa de ocho o doce horas. Los problemas de estabilidad de una máquina virtual rara vez asoman en los primeros diez minutos.

Preguntas frecuentes (FAQs)

¿Es arriesgado cambiar el motor?

No, si conservas la carpeta original renombrada. La operación es reversible en menos de un minuto y no afecta a configuraciones ni databanks.

¿Cuánto se gana en la práctica?

Los usuarios documentan entre un 15 y un 25 % más de estrategias por hora y hasta un 40 % menos de memoria, con casos concretos de databanks grandes que pasaron de saturar 64 GB a ocupar 45. Son referencias, no promesas.

¿Por qué hay comparativas que dicen que GraalVM rinde peor?

Porque miden otra cosa. En una aplicación web reactiva sensible a la latencia, una comparativa independiente encontró tiempos un 30 % peores. SQX es un proceso por lotes de larga duración, que es un perfil casi opuesto.

¿Sigue disponible GraalVM tras el anuncio de Oracle?

Sí. Lo retirado en 2025 fue el soporte comercial dentro de los productos Java SE y la inclusión del compilador experimental en el Oracle JDK. La tecnología continúa accesible bajo los términos gratuitos y en la edición abierta.