Java EE frente a J2EE frente a Yakarta EE

1. Introducción

¿Has oído hablar de Java EE? ¿Qué tal Java 2EE, J2EE o ahora Jakarta EE? En realidad, todos estos son nombres diferentes para lo mismo: un conjunto de especificaciones empresariales que amplían Java SE.

En este breve artículo, describiremos la evolución de Java EE.

2. Historia

En la primera versión de Java, las extensiones empresariales de Java eran simplemente una parte del núcleo de JDK.

Luego, como parte de Java 2 en 1999, estas extensiones se separaron de los binarios estándar y nació J2EE , o Java 2 Platform Enterprise Edition. Mantendría ese nombre hasta 2006.

Para Java 5 en 2006, se cambió el nombre de J2EE a Java EE o Java Platform Enterprise Edition. Ese nombre se mantendría hasta septiembre de 2017, cuando sucedió algo importante .

En septiembre de 2017, Oracle decidió ceder los derechos de Java EE a Eclipse Foundation (el lenguaje aún es propiedad de Oracle) .

3. En transición

En realidad, la Fundación Eclipse tuvo que renombrar legalmente Java EE. Eso es porque Oracle tiene los derechos sobre la marca "Java".

Entonces, para elegir el nuevo nombre, la comunidad votó y eligió: Yakarta EE. De alguna manera, sigue siendo J EE.

* Nuevo nombre anunciado

Sin embargo, esta sigue siendo una historia en evolución y el polvo no se ha asentado por completo.

Por ejemplo, mientras que Oracle abrió el código fuente, no abrió toda la documentación. Todavía hay mucha discusión sobre este asunto debido a cuestiones legales que dificultan la documentación de código abierto relacionada, por ejemplo, con JMS y EJB.

Aún no está claro si la nueva documentación de Eclipse Foundation podrá hacer referencia a los originales.

Además, curiosamente, la Fundación Eclipse no puede crear ningún paquete Java nuevo utilizando el espacio de nombres javax , pero puede crear nuevas clases y subclases debajo de las existentes.

La transición también significa un nuevo proceso para agregar especificaciones a Jakarta EE. Para entenderlo mejor, echemos un vistazo a cómo era ese proceso en Oracle y cómo cambia en Eclipse Foundation.

4. El futuro

Históricamente, para que una característica se convirtiera en "EE", necesitábamos tres cosas: una especificación, una implementación de referencia y pruebas. Cualquiera de la comunidad podría proporcionar estas tres cosas, y un Comité Ejecutivo decidiría cuándo estaban listas para agregarse al lenguaje.

Para comprender mejor el proceso anterior, echemos un vistazo más de cerca a qué son JSR, Glassfish y TCK y cómo incorporaron las nuevas características de EE .

También veremos qué esperar en el futuro.

4.1. El JCP y ahora, el EFSP

En el pasado, el proceso mediante el cual nació una nueva característica de EE se llamaba Java Community Process (JCP).

Java SE todavía usa el JCP en la actualidad. Pero, dado que EE ha cambiado su propiedad, de Oracle a Eclipse Foundation, tenemos un proceso nuevo y separado para eso. Es el proceso de especificación de la base de Eclipse (EFSP) y es una extensión del proceso de desarrollo de Eclipse.

Sin embargo, existen algunas diferencias importantes, principalmente en torno a la “transparencia, apertura, carga compartida y neutralidad del proveedor”. Los organizadores de EFSP, por ejemplo, visualizan grupos de trabajo colaborativos que sean neutrales con respecto al proveedor, un proceso de certificación que sea de autoservicio y una organización que opere y gobierne como una meritocracia.

4.2. JSR

En el JCP, el primer paso para agregar una función a EE fue crear una solicitud de especificación JSR o Java. El JSR era un poco como la interfaz de una función EE. El Comité Ejecutivo de JCP revisó y aprobó un JSR completo, y luego los contribuyentes de JSR lo codificarían y lo pondrían a disposición de la comunidad.

Un buen ejemplo de esto fue JSR-339, o JAX-RS, que se propuso originalmente en 2011, fue aprobado por JCP en 2012 y finalmente lanzado en 2013.

Y aunque la comunidad siempre podía intervenir mientras se discutía una especificación, el tiempo mostró que un enfoque de implementación primero, como en el caso de JSR 310, java.time y Joda Time, tendía a crear características y API más ampliamente aceptadas. .

Por lo tanto, el EFSP refleja esta visión de código primero en su objetivo declarado: "EFSP se basará primero en la experimentación práctica y la codificación, como una forma de demostrar que algo es digno de documentarse en una especificación".

4.3. Glassfish

Luego, como parte del JCP, un JSR necesitaba una implementación de referencia. Esto es un poco como la clase que implementa la interfaz . Una implementación de referencia ayuda a los desarrolladores de bibliotecas compatibles u otras organizaciones que desean crear su propia implementación de la especificación.

Para las funciones de Java EE, el JCP utilizó Glassfish para sus implementaciones de referencia.

Y aunque esta centralización en Glassfish simplificó el proceso de descubrimiento para los implementadores, esa centralización también requería más gobernanza y tenía una tendencia a favorecer a un proveedor sobre otro.

Por lo tanto, el EFSP no requiere una implementación de referencia, sino solo una implementación compatible . En pocas palabras, este cambio sutil hace que las implementaciones dentro de una arquitectura central, como Glassfish, no sean preferidas sin darse cuenta por la fundación.

4.4. TCK

Finalmente, el JCP requería que las características de EE se probaran a través del Kit de compatibilidad tecnológica, o TCK.

El TCK era un conjunto de pruebas para validar un EE JSR específico. En pocas palabras, para cumplir con Java EE, un servidor de aplicaciones necesita implementar todos sus JSR y pasar todas las pruebas en el TCK designado.

No hay muchos cambios aquí. Oracle abrió el TCK y los EE JSR. Por supuesto, todos los documentos futuros y el TCK serán de código abierto.

5. Conclusión

Java EE ciertamente ha evolucionado mucho durante esos años. Es bueno ver que continúa cambiando y mejorando.

Hay muchos desafíos por delante, así que esperemos una transición sin problemas.