Header Ads Widget

Ticker

6/recent/ticker-posts

Introducción a GraalVM (Community Edition): GraalVM para aplicaciones JVM

 

1. Introducción

En esta parte del tutorial, continuaremos nuestro viaje para aprender más sobre el proyecto GraalVM , enfocándonos específicamente en la integración con la plataforma JVM. Para comprender cómo encaja GraalVM en la imagen general, probablemente deberíamos comenzar descomponiéndolo en un conjunto de bloques de construcción.

2. Descomposición de GraalVM

En la parte anterior del tutorial discutimos brevemente algunos de los componentes clave en los que consta GraalVM , pero seguramente hay más. Reiterémoslos brevemente.

Si bien más adelante hablaremos de las capacidades políglotas de GraalVM , lo que nos interesa en el contexto de la integración de JVM son el compilador GraalVM , Substrate VM y un subconjunto de herramientas aplicables. Cuando descarga la distribución de GraalVM para la plataforma de su elección, obtiene la mayoría de estos componentes incluidos. Un hecho que quizás no sepa es que el compilador de GraalVM podría estar ya disponible (pero no activado de forma predeterminada) en el Distribución JDK que está utilizando hoy para ejecutar sus aplicaciones y servicios.

3. Usando GraalVM con OpenJDK

La capacidad de compilación anticipada (también conocida como JEP-295 ), herramienta jaotc , se introdujo por primera vez en la versión OpenJDK 9 como una función experimental. Era usando GraalVM compilador como backend generar código. Poco después, en el ámbito de JEP-317 ( compilador JIT experimental basado en Java ) incluido en la versión OpenJDK 10 , el propio compilador GraalVM estuvo disponible como compilador JIT experimental.

Después del ciclo de lanzamiento de seis meses, tanto OpenJDK 9 como OpenJDK 10 han llegado al final de su vida útil hace un tiempo. Hablando de manera realista, a partir de hoy, la mayoría de las aplicaciones y servicios de JVM todavía se ejecutan en JDK 8, lo que básicamente significa que jaotc y el compilador GraalVM están fuera de alcance (alerta de spoiler; más sobre esto en breve) en la mayoría de las implementaciones.

Pero lo más probable es que esté ejecutando la versión LTS , como OpenJDK 11 , o equilibrando la vanguardia con OpenJDK 15 (la última versión de OpenJDK disponible a partir de hoy). En cualquier caso, está listo para beneficiarse del compilador GraalVM, pero aún está marcado como una característica experimental. Para activarlo, es suficiente agregar los -XX:+UnlockExperimentalVMOptions  -XX:+UseJVMCICompilerargumentos de la línea de comandos a las opciones de inicio de su JVM.

1
$ java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler <...>

Para ser estrictos, también tenemos que agregar -XX:+EnableJVMCIpero se enciende automáticamente cuando la -XX:+UseJVMCICompileropción está presente. Más importante aún, el compilador GraalVM no se carga como una biblioteca compartida nativa ya que no está presente en las distribuciones de OpenJDK por defecto. Si lo tiene disponible, podría habilitarse mediante el uso de dos opciones de línea de comando adicionales -XX:+UseJVMCINativeLibrary-XX:JVMCILibPath=<path>, introducido desde el lanzamiento de OpenJDK 13 . Por último, pero no menos importante, consulte JDK-8232118 para conocer más formas de modificar los argumentos de la línea de comandos de JVMCI .

Vale la pena señalar que JVMCI y el compilador GraalVM tienen una serie de opciones configurables que podrían especificarse mediante propiedades del sistema con el prefijo jvmci.*graal.*respectivamente. Estas propiedades deben establecerse en la línea de comandos de JVM y la lista de todas las propiedades admitidas se puede recuperar al incluir el -XX:+JVMCIPrintPropertiesargumento de la línea de comandos.

1
$ java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+JVMCIPrintProperties

Pero, ¿qué pasa si estás atrapado con JDK 8 ? Si el cambio a una distribución GraalVM respectiva no es una opción para usted, considere echar un vistazo a la bifurcación de jdk8u / hotspot con soporte para JVMCI . Debería poder encontrar una distribución habilitada para JVMCI para su versión exacta de JDK 8 o incluso crear la suya propia.

Como punto extra, cambiar el compilador JIT no requiere ningún cambio en las aplicaciones y / o servicios existentes, ya que se espera que se ejecuten de forma totalmente compatible desde el primer momento . Aún así, GraalVM! = JVM , es mejor realizar conjuntos de pruebas integrales para identificar posibles regresiones u otros problemas. Pero primero, ¿cómo puede saber si su JVM está usando el compilador GraalVM ? Hay muchas formas de recopilar la prueba, pero probablemente la más fácil y visualmente agradable es usar JDK Mission Control o VisualVM . Mientras que la inspección se ejecutan los procesos de JVM en cuestión, debe ser capaz de detectar adicionales JVMCI hilos compilador y compilador GraalVM en sus rastros de pila.

GraalVM para JVM: subprocesos del compilador JVMCI y compilador GraalVM en seguimientos de pila
Hilos del compilador JVMCI y compilador GraalVM en seguimientos de pila

¿Cómo se ve el futuro de la integración de GraalVM con OpenJDK ? Los planes aún no están claros, pero los principales cambios ya se están incorporando en el próximo lanzamiento de OpenJDK 16 . La herramienta jaotc desapareció y el trabajo adicional para integrar Graal en OpenJDK se ha trasladado al Proyecto Metropolis . Tal vez valga la pena investigar las distribuciones de GraalVM después de todo.

4. Uso de la distribución GraalVM

El 20.3.0es el último lanzamiento de la Comunidad GraalVM al momento de escribir este artículo. Tiene dos sabores: OpenJDK 8 y 11. El primero está basado en la versión OpenJDK1.8.272 mientras que el segundo en la versión OpenJDK11.0.9 . La distribución respectiva para la plataforma de su elección se puede descargar directamente desde la página oficial de Github del proyecto .

Además de la compatibilidad con JVMCI y libgraal , el compilador GraalVM compilado con anticipación en una biblioteca compartida nativa, la distribución incluye:

  • VisualVM, que incluye funciones de análisis de montón para los idiomas invitados admitidos
  • GraalVM Updater : una utilidad de línea de comandos que se utiliza para instalar y administrar los tiempos de ejecución y las utilidades del lenguaje GraalVM opcionales

A lo largo del resto del tutorial, usaremos GraalVM 20.3.0 con OpenJDK 11. Lo único que tiene que cambiar es apuntar su JAVA_HOMEvariable de entorno a la distribución de GraalVM . La documentación oficial tiene una serie de guías para ayudarlo a comenzar.

Para muchas aplicaciones y servicios de JVM, esto podría ser suficiente, pero no nos detendremos aquí. Hablemos de Substrate VM y la compilación anticipada ( AOT ) de aplicaciones Java / JVM en imágenes ejecutables u objetos compartidos (denominados colectivamente imagen nativa ).

5. Convertirse en nativo

La capacidad de producir ejecutables nativos o bibliotecas compartidas es probablemente la característica más exigente de GraalVM . ¿Qué queda debajo de la cortina? Intentemos averiguarlo.

5.1. VM de sustrato

Si Substrate VM no le suena, no se preocupe, es poco probable que haya oído hablar de ello. Sin embargo, esta es la fuerza impulsora detrás de la compilación anticipada ( AOT ) y el empaquetado de ejecutables independientes nativos de las aplicaciones y servicios de JVM. Pero, ¿cómo es posible que se pregunte?

Cualquier código escrito para JVM necesita que se ejecute JVM. No solo incluye JIT, sino también un recolector de basura, programación de subprocesos y muchos otros componentes de tiempo de ejecución. Cuando la aplicación o servicio de JVM se empaqueta como ejecutable nativo, la JVM ya no es necesaria. Pero todavía se requieren los mismos componentes de tiempo de ejecución que proporciona la JVM. Esto es exactamente lo que hace Substrate VM : se convierte en parte del ejecutable nativo y sirve como proveedor de estos servicios necesarios.

Genial, se descubre al menos un misterio de cómo los ejecutables nativos se han convertido en algo real. Es hora de ver cómo podemos construir imágenes nativas.

5.2. Generador de imágenes nativas

El ecosistema GraalVM viene con una herramienta llamada imagen nativa , también conocida como native image builderNo es parte de la distribución sino un componente opcional.

El generador de imágenes nativas o imágenes nativas es una utilidad que procesa todas las clases de una aplicación y sus dependencias, incluidas las del JDK. Analiza estáticamente estos datos para determinar qué clases y métodos son accesibles durante la ejecución de la aplicación. Luego, compila con anticipación ese código y datos accesibles en un ejecutable nativo para un sistema operativo y una arquitectura específicos. Todo este proceso se denomina creación de una imagen (o el tiempo de creación de la imagen) para distinguirla claramente de la compilación del código fuente de Java en código de bytes.

https://www.graalvm.org/reference-manual/native-image/

Se puede instalar con gu (también conocido como GraalVM Updater ), una utilidad de línea de comandos que se utiliza para instalar y administrar componentes opcionales de GraalVM .

1
$ gu install native-image

La imagen nativa es compatible no solo con Java, sino con todos los lenguajes basados ​​en JVM. Antes de emocionarse demasiado, vale la pena señalar que no todas las aplicaciones o servicios pueden empaquetarse como imágenes nativas (ya sea ejecutable o biblioteca compartida). Hay una serie de limitaciones que debe conocer y, para ciertos tipos de aplicaciones / servicios, es posible que no sea práctico volverse nativo.

La documentación oficial cubre la  imagen nativa con gran detalle, y hay muchos que justificar. No vamos a copiar / pegar todo eso, sino que destacaremos los temas y áreas más interesantes a los que prestar especial atención.

Con imágenes nativas, ya no hay JIT involucrado. Todo el código está precompilado en instrucciones de máquina que dependen de la plataforma de destino. Sin embargo, lo que es interesante es que el proceso de generación de imágenes nativas se divide en dos fases: tiempo de construcción y tiempo de ejecución. Esta es una de las razones por las que los argumentos de la línea de comandos del ejecutable de la imagen nativa se dividen en dos grupos distintos:

  • Prefijado con –H(opciones alojadas): configure una compilación de imagen nativa
  • Prefijado con –R(opciones de tiempo de ejecución): los valores iniciales se establecen durante la creación de una imagen nativa, pero podrían anularse en tiempo de ejecución (generalmente con el -XXprefijo).

Se recomienda realizar la mayor cantidad de inicialización posible durante la fase de compilación para reducir el tiempo de inicio. Por defecto, las clases se inicializan en el tiempo de ejecución de imagen pero este comportamiento es a través ajustables --initialize-at-build-time o  --initialize-at-run-time las opciones de línea de comandos. Para rastrear qué clases se inicializaron y por qué, pase la útil -H:+PrintClassInitializationopción de línea de comando.

Incluso siendo ejecutable nativo, su aplicación o servicio consume memoria. Los valores de almacenamiento dinámico adecuados serán determinados automáticamente basados en la configuración del sistema y la GC utilizado, pero es todavía posible para proporcionar su propia configuración con el -Xmx-Xms-Xmnlas opciones de línea de comandos en tiempo de ejecución.

1
$ <your native executable> -Xmx32m -Xms16m

Con preferencia, la imagen nativa ejecutable le da una opción de pre-establecer los mismos valores de almacenamiento dinámico en tiempo de construcción que utilizan -R:MaxHeapSize-R:MinHeapSizey las -R:MaxNewSizeopciones de línea de comandos, respectivamente.

1
$ native-image -R:MaxHeapSize=32m -R:MinHeapSize=16m ...

Es muy importante pensar de antemano en los requisitos de memoria esperados, ya que el recolector de basura ( GC ) predeterminado (y único ) disponible en la edición de la comunidad GraalVM para imágenes nativas es Serial GC . Está optimizado para una huella de memoria baja y tamaños de pila pequeños. Además, se aplican algunas limitaciones: tenga en cuenta que los finalizadores no se invocan. Esta característica en particular ha quedado obsoleta hace mucho tiempo y se recomienda reemplazarla con referencias débiles o colas de referencia.

El manejo de las propiedades del sistema necesita sus propias menciones. Puede usarlos con sus imágenes nativas de la manera habitual, aplicando el –Dprefijo, pero recuerde la separación de las etapas de construcción y ejecución:

  • Pasar -D<key>=<value>al ejecutable de imagen nativa afecta las propiedades vistas en el momento de la creación de la imagen
  • Pasar -D<key>=<value>a un ejecutable de imagen nativo afecta las propiedades que se ven en el tiempo de ejecución de la imagen

Desde el lanzamiento de GraalVM 20.3.0 , la imagen nativa se ha vuelto consciente de los contenedores: en Linux, los límites de recursos como el número de procesadores y el tamaño de la memoria disponible se leen de las configuraciones de cgroup . El recuento de procesadores también se puede anular en la línea de comando usando la opción ( -XX:ActiveProcessorCount=N). Además, para entornos en contenedores, es muy conveniente incluir los mismos manejadores de señales que tiene JVM. La --install-exit-handlersopción de línea de comando nos da eso.

Otra cosa, con la imagen nativa , solo un subconjunto de protocolos de URL es compatible de forma predeterminada, por lo que puede comenzar con una huella mínima y agregar funciones más adelante. Para habilitar los protocolos HTTP y / o HTTPS , debe pasar --enable-httpy / o --enable-httpsargumentos de línea de comando al ejecutable de imagen nativa . Alternativamente, puede preferir usar la --enable-url-protocolsopción de línea de comando que acepta una lista detallada de los protocolos de URL para habilitar.

El mismo razonamiento para agrupar solo los servicios de seguridad básicos de forma predeterminada está detrás del soporte de Java Cryptography Architecture ( JCA ) en el generador de imágenes nativas . Los servicios de seguridad de JCA adicionales deben habilitarse al incluir la --enable-all-security-servicesopción de línea de comando (que está activada de forma predeterminada cuando se habilita la compatibilidad con el protocolo HTTPS URL).

Un comentario final sobre el registro: fuera de la caja, la imagen nativa admite capacidades de registro utilizando solo las java.util.logging API .

Tratar con proxies dinámicos , reflexión y recursos probablemente causaría más dolores de cabeza a la mayoría de los desarrolladores. Afortunadamente, el uso de la configuración asistida de construcciones de imágenes nativas podría reducir sustancialmente los esfuerzos necesarios para empaquetar con éxito las aplicaciones y servicios existentes como imágenes nativas. Básicamente, se basa en el agente de Java que hace la introspección en tiempo de ejecución y luego vuelca todas las configuraciones requeridas.

El ejecutable independiente nativo es probablemente el tipo de imagen nativa que va a producir con mayor frecuencia, sin embargo, también puede empaquetar una biblioteca compartida (si es necesario) proporcionando el --sharedargumento de la línea de comandos al generador de imágenes nativas .

5.3. Estampación

La mayoría de los proyectos en la plataforma JVM utilizan Apache Maven , Gradle o SBT como herramienta de orquestación de compilación. La generación de imágenes nativas como parte del proceso de compilación está muy bien respaldada por todos ellos, gracias al ecosistema de complementos.

A continuación se muestra el recorte de la definición de compilación de Apache Maven que produce el ejecutable nativo junto con los artefactos JAR normales.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
dieciséis
17
18
<plugin>
    <groupId>org.graalvm.nativeimage</groupId>
    <artifactId>native-image-maven-plugin</artifactId>
    <version>20.3.0</version>
    <executions>
        <execution>
            <goals>
                <goal>native-image</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
    <configuration>
        <mainClass>...</mainClass>
        <imageName>...</imageName>
        <buildArgs>...</buildArgs>
    </configuration>
</plugin>

Para muchos proyectos existentes, es posible que deba ir más allá de las configuraciones simples y explotar las técnicas avanzadas como la sustitución de clases o métodos completos durante la construcción de la imagen. GraalVM proporciona una forma de hacerlo incorporando las API de Substrate VM .

1
2
3
4
5
6
<dependency>
    <groupId>org.graalvm.nativeimage</groupId>
    <artifactId>svm</artifactId>
    <version>20.3.0</version>
    <scope>provided</scope>
</dependency>

Para beneficiarse de las capacidades políglotas de GraalVM dentro de las aplicaciones y servicios existentes, puede utilizar un SDK oficial de GraalVM , una colección de API para los componentes de GraalVM .

1
2
3
4
5
6
<dependency>
    <groupId>org.graalvm.sdk</groupId>
    <artifactId>graal-sdk</artifactId>
    <version>20.3.0</version>
    <scope>provided</scope>
</dependency>

Además de los líderes, es muy probable que la herramienta de compilación y / o el marco de su elección ya brinden una experiencia bastante fluida con respecto a las imágenes nativas y GraalVM en general. Pero en cualquier caso, siempre puede volver a llamar directamente a las herramientas de línea de comandos.

5.4. Depuración y resolución de problemas

Debido a que el constructor de imágenes nativas genera un binario nativo, este último no incluye la implementación de la Interfaz de herramienta de máquina virtual Java ( JVMTI ) y las técnicas de depuración estándar de JVM no funcionarán. Los depuradores nativos como gdb y otros son las únicas opciones para comprender lo que sucede dentro de las imágenes nativas en tiempo de ejecución. Por las mismas razones, las herramientas destinadas a trabajar con el código de bytes de JVM no son compatibles en absoluto.

Además del tiempo de ejecución, puede solucionar problemas de la fase de creación de la imagen. Es suficiente agregar la --debug-attach[=<port>]opción de línea de comando y adjuntar el depurador durante la generación de la imagen.

Para obtener información sobre la recolección de basura, puede agregar las siguientes opciones de línea de comando al ejecutar una imagen nativa:

  • -XX:+PrintGC: imprime información básica para cada recolección de basura
  • -XX:+VerboseGC: imprime más detalles sobre la recolección de basura

¿Qué pasa con los volcados de pila que puede preguntar? No es posible activar la creación de un volcado de pila utilizando herramientas de línea de comandos estándar que vienen con OpenJDK , ni con JDK Mission Control o VisualVM . Pero puede usar GraalVM SDK e implementar la generación de volcados de pila desde su aplicación o servicio mediante programación.

6. ¿Nativo o JIT?

Una vez que aprenda la forma de empaquetar sus aplicaciones y servicios Java como imágenes nativas, aquí viene la ilustración: ¿por qué alguien debería volver atrás y usar la JVM? Como siempre, la respuesta a esta pregunta es “depende” y vamos a resumir los pros y los contras de ambos.

6.1. Imagen nativa (SubstrateVM)

Los beneficios de ejecutar aplicaciones y servicios JVM como ejecutables nativos son tremendos, pero también lo son los inconvenientes y limitaciones.

En el lado de los pros:

  • ejecutables nativos autónomos
  • tiempos de inicio muy rápidos
  • menor huella de memoria
  • tamaño ejecutable más pequeño
  • rendimiento más predecible  

En el lado de los contras:

  • sin compilador JIT, por lo que el rendimiento máximo puede no ser óptimo
  • solo recolector de basura simple (en caso de edición comunitaria)
  • no siempre es fácil empaquetar una imagen nativa
  • la creación de imágenes es muy lenta (pero el tiempo está mejorando)
  • herramientas como JDK Flight Recorder ( JFR ) aún no son compatibles
  • necesidad de utilizar depuradores nativos

Entonces, ¿qué tipo de aplicaciones y servicios se beneficiarán más al estar empaquetados como imagen nativa? Aquellos para los que las siguientes afirmaciones son verdaderas:

  • El tiempo de inicio importa
  • La huella de memoria importa
  • Montones de tamaño pequeño a mediano (pocos gigabytes como máximo)
  • Todo el código se conoce de antemano
  • El rendimiento óptimo no es la principal preocupación

Si está pensando en FaaS y sin servidor , estos son probablemente los mejores ejemplos para señalar.

6.2. JVM con el compilador GraalVM

Por el lado contrario, enumeremos los beneficios y los inconvenientes de ejecutar aplicaciones JVM en Java HotSpot VM pero en conjunto con el compilador GraalVM .

En el lado de los pros:

  • Es solo JVM regular
  • Excelente rendimiento máximo (gracias a las optimizaciones JIT)
  • Tamaños de pila grandes o pequeños
  • Una gama de recolectores de basura disponibles
  • Muchas herramientas familiares

En el lado de los contras:

  • Huella habitual de una JVM (podría reducirse con jlink )
  • Cuenta los tiempos de inicio de JVM
  • Puede tardar más que C2 en alcanzar el máximo rendimiento

Las conclusiones sensatas en este punto es que, afortunadamente, es mejor que ejecute sus aplicaciones y servicios de la manera tradicional (JVM con compilador GraalVM ) a menos que haya ventajas obvias para convertirse en nativo.

6.3. ¿Qué pasa con el compilador GraalVM?

Espero que se aclaren un poco las ventajas y desventajas de ejecutar sus aplicaciones y servicios de forma nativa frente a JVM / JIT . Pero no debemos olvidar el hecho de que las mismas consideraciones se aplican al compilador GraalVM ya que podría usarse como libgraal (como una imagen nativa precompilada) o jargraal ( código de bytes ejecutado dinámicamente).

Aunque libgraal es el modo de operación predeterminado y recomendado, tenga en cuenta que hay algunas consecuencias:

  • Dado que esta es una imagen nativa, es posible que no alcance el mismo rendimiento máximo que jargraal
  • El tamaño de la biblioteca compartida es notable.

Por otro lado, jargraal no es todo rosas y también expone una serie de defectos:

  • Ser código de bytes significa que interfiere con el código de bytes de la aplicación, incluido el montón, cachés de código, optimizaciones, ...
  • Puede llevar tiempo llegar al modo de funcionamiento óptimo

Se podría desbloquear una medición más directa de la velocidad de compilación con la -XX:+CITimeopción de línea de comando. Seguir las recomendaciones y ceñirse a libgraal es probablemente una decisión acertada; sin embargo, siempre es bueno comprender por qué lo está intercambiando.

7. GraalVM y otras JVM

Hasta ahora siempre nos hemos referido a OpenJDK y Java HotSpot VM como las plataformas con las que se integra GraalVM . ¿Qué pasa con otras máquinas virtuales Java, podría usar el compilador GraalVM con Eclipse OpenJ9 , digamos? Desafortunadamente, parece que no es posible en este momento ya que Eclipse OpenJ9 aún no implementa JVMCI (el requisito previo necesario para conectar el compilador GraalVM ). Los planes sobre el posible soporte de JVMCI son inciertos.

8. GraalVM VisualVM

La herramienta VisualVM se mencionó varias veces a lo largo de esta parte del tutorial. Es una excelente manera de obtener información visual sobre las aplicaciones y los servicios que se ejecutan en JVM. Solía ​​ser parte de la distribución JDK, pero se eliminó en Oracle JDK 9 en adelante.

Desde entonces VisualVM ha trasladado a la GraalVM y estuvo disponible en dos distribuciones: autónomo (Java VisualVM ) y liado con GraalVM distribución. Como este último, VisualVM añade un soporte especial para los GraalVM características políglotas como el análisis de las aplicaciones a nivel de lengua invitada: JavaScript, Python, Ruby y R idiomas son compatibles .

9. GraalVM en su IDE

Si descarga la distribución GraalVM , en su IDE se siente (y se ve) como una distribución OpenJDK normal , no hay sorpresas aquí. En el caso de Apache Netbeans , IntelliJ Idea o Eclipse , se aplica la misma experiencia de desarrollo, ejecución y depuración de sus aplicaciones y servicios JVM.

Además, la integración con Visual Studio Code es convenientemente proporcionada por GraalVM Extension (en una etapa de vista previa de la tecnología).

El objetivo principal de crear GraalVM VS Code Extension es habilitar un entorno políglota en VS Code , para que sea adecuado y conveniente trabajar con GraalVM desde un entorno de desarrollo integrado, para permitir a los usuarios de VS Code editar y depurar aplicaciones escritas en cualquiera de los GraalVM admite lenguajes dinámicos (JS, Ruby, R y Python).

https://www.graalvm.org/tools/vscode/graalvm-extension/

Según la experiencia personal, en los últimos años, Visual Studio Code ha ganado mucha tracción entre los desarrolladores de Java y Scala. Se ha convertido en el IDE predeterminado para muchos y la presencia de la extensión GraalVM dedicada solo se acumula en otras ventajas.

10. Estudios de caso

Es hora de echar un vistazo a algunos proyectos muy populares en el ecosistema JVM y seguir su ruta hacia el soporte de GraalVM e imágenes nativas en particular. Esas son las marcas bien establecidas con muchos años de desarrollo activo detrás, nacidas en el momento en que GraalVM ni siquiera existía todavía. No dude en utilizarlos como planos para su propia aplicación y servicios.

10.1. Netty

Netty es uno de los marcos fundamentales para la creación de aplicaciones de red de alto rendimiento en la JVM. Su popularidad se ha disparado en los últimos años, en parte debido a la adopción generalizada del paradigma de programación reactiva.

Netty es un marco de aplicación de red asincrónico controlado por eventos para el desarrollo rápido de servidores y clientes de protocolo de alto rendimiento que se pueden mantener.

https://netty.io/

Por supuesto, Netty se encuentra entre los primeros partidarios de GraalVM, que a su vez despejó (o al menos, simplificó) el camino para que los proyectos iniciales siguieran el ejemplo.

10.2. Primavera

En la JVM, la plataforma Spring era y sigue siendo una pila técnica dominante para crear todo tipo de aplicaciones y servicios. Es una producción muy madura, probada en batalla, su portafolio es muy impresionante y es realmente difícil encontrar un proyecto más o menos popular con el que Spring no tenga integración. Eso es una fortaleza y una debilidad al mismo tiempo, particularmente cuando las decisiones de implementación técnica central están en conflicto con las limitaciones actuales de GraalVM .

A partir de hoy, el soporte de imágenes nativas de los proyectos de Spring está marcado como experimental y está alojado en un repositorio separado . Se implementa en gran medida aprovechando las capacidades de sustitución avanzadas proporcionadas por las API de Substrate VM . Con suerte, para cuando Spring Framework 6 vea las luces, la etiqueta experimental se eliminará, lo que hará que las aplicaciones y servicios basados ​​en Spring admitan imágenes nativas y estén listas para el horario de máxima audiencia.

11. El camino por delante

La mejor manera de concluir nuestra discusión es tocar los desarrollos actuales y futuros destinados a eliminar una serie de limitaciones existentes, especialmente asociadas con la generación de imágenes nativas .

El ritmo de los cambios en GraalVM es extraordinario y no debería pasar mucho tiempo antes de que veamos al menos algunos de ellos abordados en las próximas versiones. Además de eso, vale la pena estar atento al siguiente trabajo en curso.

Esos son solo una selección selectiva de cientos de problemas y solicitudes de extracción. Siempre se necesita ayuda, ¡no dude en unirse a la comunidad y comenzar a contribuir!

12. Qué sigue

En la siguiente parte del tutorial, hablaremos sobre la computación en la nube , los desafíos que presenta para las aplicaciones y servicios de JVM, cómo GraalVM los está abordando y discutiremos una nueva generación de bibliotecas y marcos nativos de la nube.

Publicar un comentario

0 Comentarios