De Java EE a Jakarta 9 ¿Que hizo Oracle con J2EE?

Actualizar Java 2EE a Jakarta con la intención de mantener actualizada tu plataforma o ya sea porque quieres comenzar un nuevo proyecto con las tecnologías más recientes y Java Empresarial de por medio en un reto cuando se está separando de Oracle. La información que presento a continuación la extraje de la web de Oracle directamente, intentando ser lo mas fiel posible a su información oficial .

Java EE es sin duda uno de los marcos más reconocibles para Java del lado del servidor. Básicamente, inició la industria para usar Java en el servidor, y se remonta a los inicios de Java en 1996. Java EE, o J2EE (Java 2 Enterprise Edition) como se conocía antes, es quizás mejor conocido por su especificación Java Servlet y por servidores que lo implementan, como Tomcat y Jetty. A menudo se denominan contenedores de servlets .

Aunque existen alternativas, muchas aplicaciones de servidor y marcos de trabajo de terceros se basan en la especificación de Java Servlet. Además de esta especificación, Java EE en años posteriores se hizo conocido por sus especificaciones de persistencia (Java Persistence API [JPA], principalmente a través de Hibernate), REST (JAX-RS), WebSocket y una gran cantidad de especificaciones más pequeñas, como para transacciones (Java Transaction API [JTA], utilizada principalmente bajo las cubiertas de JPA), para validación (Bean Validation) y para JSON (JSON-P y JSON-B).

En la práctica, algunas aplicaciones que parecen no estar clasificadas como aplicaciones Java EE pueden usar una variedad de API Java EE.

Las implementaciones completas de Java EE, utilizadas tradicionalmente en servidores de aplicaciones, también han tenido un éxito considerable: JBoss / WildFly, GlassFish / Payara y, más recientemente, Open Liberty (el sucesor moderno de WebSphere) son bien conocidos.

Luego, hay un grupo de productos que no son servidores de aplicaciones ni contenedores de servlets, pero que admiten una variedad de API Java EE de fábrica. Estos incluyen Quarkus (Contextos e inyección de dependencia [CDI], JAX-RS, JPA), Helidon (CDI, JAX-RS, JPA, JTA), KumuluzEE (CDI, JAX-RS, JPA, Servlet, JavaServer Faces [JSF], WebSocket, Bean Validation, JSON-P) y Piranha (CDI, JAX-RS, Java EE Security, Expression Language [EL]).

Finalmente, está la plataforma de descendientes Java EE llamada MicroProfile, que depende directamente de las API de Java EE, como CDI, JAX-RS y JSON. En conjunto, esto hace que las API Java EE sean bastante relevantes para un gran grupo de usuarios.

Al grano, ¿Qué ha estado sucediendo con Java EE?

La última versión de Java EE propiamente dicha fue Java EE 8 en agosto de 2017. Esta fue una versión de alcance reducido, aunque contenía funciones clave importantes, como Java EE Security. Oracle decidió más tarde ese año transferir Java EE completamente a una base de código abierto. En coordinación con los socios de Java EE, Red Hat e IBM, se decidió transferir Java EE junto con la implementación de referencia completa y el Kit de compatibilidad de tecnología (TCK) a la Fundación Eclipse.

Debido a la enorme cantidad de trabajo involucrado con esta transferencia, el proceso se dividió en tres etapas.

Etapa 1: Transferencia del API y el código de implementación y se libera una compilación verificada. 

La primera etapa consistió en crear un nuevo proyecto de nivel superior en Eclipse llamado Eclipse Enterprise para Java (EE4J) . El proyecto EE4J y su organización GitHub asociada, eclipse-ee4jz , albergan tanto los proyectos de especificación como de implementación. EE4J no debe confundirse con la nueva marca de Java EE, Jakarta EE, que fue seleccionada varios meses después por la comunidad.

Antes de poder realizar la transferencia real de todo el código fuente existente desde el repositorio de Oracle en github.com/javaee, todo el código tenía que ser borrado legalmente, lo que entre otras cosas significaba que debían eliminarse partes potencialmente controvertidas. Con un peso de muchos millones de líneas de código, esta no fue una tarea fácil. Aplicar esta compensación legal a todo el código histórico también habría sido simplemente imposible de deshacer. Por lo tanto, lo primero a tener en cuenta es que solo se transfirieron las últimas versiones publicadas del código. Por ejemplo, JSF 2.3 se transfirió como una instantánea de su rama maestra. JSF 2.2 y versiones anteriores permanecen en su ubicación original y no son mantenidas ni respaldadas por la Fundación Eclipse.

Después de la transferencia del código fuente, todo el código se generó utilizando servidores de compilación Eclipse, y el resultado se organizó en un repositorio Maven. Los archivos JAR de API tuvieron su ID de grupo cambió de Maven javax.*a jakarta.*, indicando que son los artefactos de construcción producidos por Eclipse. A partir de estos, se produjo una nueva compilación de GlassFish, y contra esta compilación se ejecutó el Java EE 8 TCK original. Después de que la compilación pasó las pruebas TCK, demostrando que todo el código se transfirió con éxito, se lanzó como GlassFish 5.1.

Por cierto, la versión inicial de las API bajo la Jakarta ID de grupo tiene certificación Java EE 8, no Jakarta EE 8.

Por ejemplo, jakarta.faces:jakarta.faces-api:2.3.1 está construido desde github.com/eclipse-ee4j es idéntico a javax.faces:javax.faces-api:2.3  que está construido desde github.com/javaee donde ambos tienen certificación Java EE 8.

Etapa 2: Transferencia del código TCK, configuración de un nuevo proceso de especificación, definición de nuevos términos y se libera una compilación renombrada. 

La segunda etapa consistió en transferir el TCK y construir nuevos binarios para la certificación Jakarta EE 8. Se estableció un nuevo proceso de certificación: el Proceso de Especificación EE de Jakarta (JESP). Además, se creó una nueva licencia de especificación: la licencia del Kit de compatibilidad tecnológica de Eclipse Foundation.

En esta etapa, se crearon nuevos nombres simplificados y más consistentes para todas las especificaciones. Todos los nombres nuevos comienzan con Jakarta y son seguidos por una descripción simple de la especificación, evitando palabras de relleno inconsistentes como arquitectura , api y servicio.

Comparación términos de J2EE y Jakarta 8

El Javadoc para todas las API se actualizó en esta etapa para reflejar los nuevos términos, y los archivos API JAR resultantes se volvieron a licenciar y luego se probaron en GlassFish 5.1 con el TCK renombrado que se creó a partir del código fuente TCK transferido. Todo esto se hizo siguiendo el nuevo proceso de especificación JESP.

Los archivos API JAR resultantes se publicaron con documentos de especificación de marcador de posición casi vacíos. Estos combinados constituyen Jakarta EE 8.

Para los archivos JAR individuales, esto significa que esta etapa es la tercera versión de técnicamente la misma API, la segunda versión que usa el JakartaID de grupo Maven y la primera versión que está certificada por Jakarta EE. La Tabla 2 muestra un ejemplo para JSF / Jakarta Faces.

La Tabla 2. Ejemplo que muestra los archivos JAR para caras JSF y Jakarta

Hay dos cosas adicionales para notar aquí.

La primera es que para Jakarta EE 8, no hubo una versión correspondiente de GlassFish, aunque GlassFish 5.1 fue certificado para Jakarta EE 8 además de la certificación Java EE 8 existente.

El segundo es que, como se mencionó anteriormente, Jakarta EE 8 se lanzó con documentos de especificación esencialmente vacíos. La razón de esto es la gran cantidad de tiempo que lleva borrar legalmente y transferir esos documentos, y esto simplemente no se terminó a tiempo para el lanzamiento de Jakarta EE 8. Por ahora, los usuarios (no implementadores) de las tecnologías pueden leer la versión de evaluación de los documentos Java EE 8 correspondientes.

La actualización a las versiones Jakarta EE de las API es el primer pequeño paso que los usuarios pueden dar para prepararse para los próximos cambios más grandes. En un proyecto Maven, hacer eso es en su mayoría tan simple como reemplazar esto:

<dependency>
     <groupId>javax</groupId>
     <artifactId>javaee-api</artifactId>
     <version>8.0</version>
     <scope>provided</scope>
</dependency>

Con este:

<dependency>
     <groupId>jakarta.platform</groupId>
     <artifactId>jakarta.jakartaee-api</artifactId>
     <version>8.0.0</version>
     <scope>provided</scope>
</dependency>

O, cuando se usan dependencias individuales, reemplazando esto:

<dependency>
     <groupId>javax.faces</groupId>
     <artifactId>javax.faces-api</artifactId>
     <version>2.3</version>
     <scope>provided</scope>
</dependency>

Con este:

<dependency>
     <groupId>jakarta.faces</groupId>
     <artifactId>jakarta.faces-api</artifactId>
     <version>2.3.2</version>
     <scope>provided</scope>
</dependency>

Debido a que las API son esencialmente idénticas, debería haber algunos problemas después de esta actualización. Tenga en cuenta, sin embargo, que Maven no ve las dos dependencias relacionadas con una más nueva que la otra.

Para Maven, hay dos dependencias totalmente diferentes, y Maven felizmente las incluirá a ambas. Esto puede suceder, por ejemplo, cuando una dependencia de nivel superior incorpora de forma transitiva una dependencia Java EE. Antes de la actualización de Jakarta, una introducción transitiva javax.faces:javax.faces-api:2.2sería anulada, por ejemplo, por un nivel superior javax.faces:javax.faces-api:2.3.

Cuando esa dependencia de nivel superior se cambia a jakarta.faces:jakarta.faces-api:2.3.2, la dependencia 2.2 ya no se anulará y Maven los usará a ambos, lo que provocará todo tipo de problemas. Si la inclusión transitiva no se puede actualizar, este problema generalmente se puede solucionar mediante el uso de exclusiones, por ejemplo:

<dependency>
     <groupId>com.example</groupId>
     <artifactId>foo</artifactId>
     <scope>provided</scope>
     <exclusions>
          <exclusion>
               <groupId>javax.faces</groupId>
               <artifactId>javax.faces-api</artifactId>
          </exclusion>
     </exclusions>
</dependency>

Y todo esto nos lleva a la ultima etapa.

Etapa 3: Transferencia y actualización de los documentos de especificación, reducción de las especificaciones, cambio del nombre del paquete API y se libera JDK 11.

El paso final de la transferencia, que actualmente está en proceso y está programado para completarse más adelante este año, incluye transferir el documento de especificación código fuente (principalmente en AsciiDoc). Después del código API, el código de implementación y el código TCK, este es el artefacto final que se transferirá. Al igual que el Javadoc para las API, los documentos de especificación se actualizarán para usar la nueva terminología.

Sin embargo, el elemento de mayor impacto en esta etapa es cambiar el nombre del paquete en todas las API de Java de javax.*a jakarta.*. Por ejemplo javax.faces.context.FacesContextse convertirá jakarta.faces.context.FacesContext. La consecuencia de este cambio de nombre del paquete es que el código de las aplicaciones existentes tendrá que actualizarse, lo que lo convierte en una actualización no trivial.

Dado el gran tiempo que ha pasado desde el lanzamiento de Java EE 8, Jakarta EE 9 requerirá oficialmente soporte para JDK 11. Sin embargo, dado que JDK 8 sigue siendo tan importante, las API permanecen en JDK 8. Prácticamente, esto significa que las API deben compilarse con el nivel de código fuente JDK 8, pero las implementaciones deben pasar el TCK que se ejecuta en JDK 11.

Debido a que JDK 11 eliminó varias especificaciones que anteriormente se habían movido de Java EE a Java SE, ahora se moverán nuevamente. Jakarta Activation ingresa a Jakarta EE como una especificación requerida (específicamente porque es una dependencia requerida de Jakarta Mail), mientras que Jakarta XML Binding, Jakarta XML Web Services, Web Services Metadata y SOAP with Attachments se agregan como especificaciones opcionales.

Jakarta Enterprise Beans (anteriormente EJB) se reducirá de tamaño nuevamente. Después de que los beans de entidad (incluido el lenguaje de consulta EJB) y la API de Java para los puntos finales RPC (JAX-RPC) basados ​​en XML se podaron en EJB 3.1, ahora es el momento de podar el grupo de API EJB 2.1 (por ejemplo javax.ejb.EJBHome) y el denominado distribuido interoperabilidad

Además, la especificación de implementación (JSR 88) y la especificación de gestión (JSR 77) también se podarán. JSR 88 ya era opcional en Java EE 8, aunque JSR 77 una vez se programó para una actualización importante; sin embargo, eso no se materializó. JAX-RPC, que hace mucho tiempo fue reemplazado por JAX-WS y que ya era opcional en Java EE 8, ahora finalmente también se eliminará, junto con los Registros XML, que también era opcional en Java EE 8.

La Tabla 3 muestra el ejemplo JSF / Jakarta Faces nuevamente actualizado para Jakarta EE 9, y los cambios relacionados con Java EE 8 están en negrita. La última fila es tentativa y está sujeta a cambios aún (aunque poco probable).

Tabla 3. Ejemplo de JSF / Jakarta actualizado para Jakarta EE 9

Conclusión

Después de que Jakarta EE 9 haya sido lanzado, y presumiblemente todos los documentos de especificación hayan sido transferidos y actualizados, la transferencia de Java EE 8 se considerará realizada. En ese momento, todo lo relacionado con Java EE habrá sido trasladado a la Fundación Eclipse y actualizado a la nueva marca.

Desde el punto de vista funcional, Jakarta EE 9 sigue siendo esencialmente igual que Java EE 8, por lo que desde una perspectiva puramente funcional, ni Jakarta EE 8 ni Jakarta EE 9 son particularmente atractivos para los usuarios. Sin embargo, el propósito de esos lanzamientos es brindar a la comunidad y al ecosistema (por ejemplo, vendedores de herramientas y bibliotecas) la oportunidad de preparar sus aplicaciones y productos. Jakarta EE 10 será la primera versión en la que aparecerá una nueva funcionalidad. La Tabla 4 muestra los lanzamientos y las fechas de lanzamiento (las fechas provisionales se denotan con *).

Si quieres aprender más referente a la programación y el uso de las tecnologías que vamos publicando puedes iniciar con Éste curso