Al final del día ¿Qué es Jakarta EE?

Del sitio web de Jakarta EE se puede extraer la siguiente definición:

Jakarta EE brinda a los desarrolladores un conjunto integral de especificaciones abiertas y neutrales para el proveedor que se utilizan para desarrollar aplicaciones Java modernas y nativas de la nube desde cero.Con Jakarta EE, los desarrolladores y consumidores de tecnología pueden estar seguros de que cuentan con las mejores tecnologías para desarrollar aplicaciones de misión crítica nativas en la nube.Y pueden basarse en décadas de experiencia de los desarrolladores de Java para trasladar las cargas de trabajo existentes a la nube.

¿Qué significa esto realmente para los desarrolladores?

Uno de los puntos más fuertes de ser un desarrollador de Java es el ecosistema . En principio, el desarrollador Java puede elegir entre diferentes proveedores de JVM, frameworks, bibliotecas y entornos de ejecución. Esta ha sido la situación desde la era de Sun Microsystems y hay diferentes frameworks para diferentes necesidades, por ejemplo, si queremos crear una API REST con Java, la primera selección debe ser entre:

• Microframeworks que proporcionan un modelo de programación imperativo y comunicaciones HTTP como SparkJava o Javalin
• Frameworks «opinionated» integrales con su propia mentalidad y forma de hacer las cosas como Armeria o Akka
• Frameworks generalistas de extremo a extremo basados ​​en programación declarativa (anotaciones) y convenciones sobre configuración, como Spring Boot o Dropwizard

Con esto en mente, un desarrollador de Java normal no puede conocer todos los aspectos particulares de cada framework, por lo tanto y en muchas situaciones, su conocimiento sobre una solución no es transferible en absoluto a otras soluciones a pesar de que ambas soluciones son Java .

Esto último no es necesariamente bueno o malo, pero sin la existencia de especificaciones la programación en Java seria el viejo oeste, donde cada creador de frameworks y entornos de ejecución tendría una forma única y diferente de hacer su producto.

Siendo así, en 1998, Sun Microsystems creó el Java Community Process, una organización de estándares cuyo objetivo es proporcionar un conjunto común de especificaciones técnicas para Java Core (J2SE), Java Micro (J2ME) y Java Enterprise (J2EE). Trasladandonos al día de hoy J2EE se convirtió en Java EE, y algunos años más tarde el proceso de Java EE fue donado a la Fundación Eclipse , donde nació Jakarta EE.

Dentro de Eclipse, los proveedores de software (comunidades o empresas) podrían tomar (o proponer) una especificación, con el objetivo de tener bases técnicas comunes para definir una «forma empresarial Java» de hacer las cosas.

Un «producto» de especificación es principalmente (pero no exclusivamente) cuatro cosas: 1. Un subproyecto a cargo de la especificación, básicamente una comunidad compuesta por partes interesadas, 2. La definición de la especificación (documentación al respecto), 3. Un conjunto de Java APIs y 4. Un conjunto de pruebas de compatibilidad para validar eventuales implementaciones (TCK).

Cómo se ve Jakarta EE en la vida real

Tomemos una de las especificaciones Jakarta EE más populares, la especificación para la persistencia de objetos Java -es decir, Jakarta Persistence o JPA- .

La definición textual es:

Jakarta Persistence define un estándar para la gestión de la persistencia y el mapeo de objetos/relaciones en entornos Java®.

Como probablemente estén adivinando, esta especificación tiene (al menos) los cuatro elementos descritos anteriormente, siendo:

1. Una comunidad que dirige la especificación
2. La definición de especificación
3. Un conjunto de API de Java
4. Un TCK

Posteriormente o durante la creación de la especificación, las comunidades y empresas crean bibliotecas y/o productos Java compatibles con esta especificación, en este momento Jakarta Persistence 3.1 tiene dos implementaciones:

1. EclipseLink (Eclipse)
2. Hibernate (Red Hat)

En términos prácticos, esto significa que tanto EclipseLink como Hibernate son bibliotecas que proporcionan el código fuente para satisfacer el objetivo de Jakarta Persistence, se prueban contra TCK y tienen un comportamiento predecible donde su conocimiento sobre Jakarta Persistence funciona en ambas bibliotecas. Si el desarrollador Java decide permanecer en la especificación, su código será portátil entre implementaciones porque se utilizan igual, con las mismas anotaciones, las mismas interfaces Java y el mismo estilo de programación.

Al mismo tiempo, cada proyecto proporciona capacidades adicionales, como ser compatible con algún caché en particular, por ejemplo, Infinispan e Hibernate , o tener funciones adicionales para algunas bases de datos en particular, por ejemplo, EclipseLink y Oracle . Si se decide utilizar las capacidades adicionales, es probable que el código Java no sea portátil entre las implementaciones, pero aún así tendrá la forma y el estilo empresarial de hacer las cosas.

Colecciones de especificaciones y entornos de ejecución certificados

Algunas especificaciones de Jakarta son más populares que otras y, lo que es más importante , no todas las comunidades o empresas de Java adoptarán todas las especificaciones.

Por ejemplo, tanto Spring Boot como Micronaut ofrecen capas de datos de abstracción sobre Jakarta Persistence, pero cada uno tiene su propia forma de definir APIs REST ( Spring , Micronaut ).

Por otro lado, si una empresa o comunidad determinada decide adoptar completamente Jakarta EE, puede crear productos certificados con los perfiles de Jakarta EE, siendo estos :

• Jakarta EE Core: ofrece un conjunto minimalista de especificaciones para la creación de servicios REST
• Jakarta EE Web: Ofreciendo un conjunto de especificaciones para crear aplicaciones Web
• Jakarta EE Full: Ofreciendo un conjunto completo de especificaciones para productos que necesitan ofrecer un conjunto sólido de características para cualquier tipo de aplicaciones Java Enterprise

Una vez más, un producto dado podría apuntar al mínimo para cumplir con Jakarta EE Core, pero aún así ofrecer muchos extras con su propia mentalidad y no necesariamente compatible con Jakarta EE Full, como Quarkus que probablemente va a certificarse contra Jakarta EE 10 core.

Así mismo, no todos los entornos de ejecución son iguales, si damos un vistazo rápido a implementaciones compatibles vamos a encontrar diferentes categorías, como:

Entornos para la creación de microservicios modulares sobre FastJars, Docker o Kubernetes:

• OpenLiberty (JakartaEE 10 Core)
• Wildfly Bootable Jar (Jakarta EE 10 Full)

Entornos para la creación de UberJars independientes sobre Docker o Kubernetes:

• Payara Micro (JakartaEE 10 Web)
• Apache TomEE (Jakarta EE 9.1 Web)

Servidores de aplicaciones completos

• Oracle WebLogic (Jakarta EE 8 Full)
• Eclipse Glassfish (Jakarta EE 10 Full)
• JBoss EAP (Jakarta EE 8 Full)

¿Cuál es mejor?

Como todo en TI, esto depende de la necesidad.

Personalmente tiendo a preferir Payara si necesito un servidor independiente, principalmente porque tengo considerable experiencia en Glassfish. Además, si necesito distribuir una aplicación simple en un fatjar, tiendo a usar Payara Micro o Apache TomEE .

Si necesito una arquitectura de microservicios, probablemente usaré Quarkus o Helidon .

Si necesito una función lambda, Quarkus seguramente.