Java EE vs J2EE vs Jakarta EE

Esta ainda é uma história em evolução, porém, e a poeira não baixou completamente.

For example, while Oracle open-sourced the source code, they did not open-source all the documentation. Ainda há muita discussão sobre esse assunto por causa de questões legais que tornam difícil a documentação de código aberto relacionada a, por exemplo, JMS e EJB.

Ainda não está claro se a nova documentação da Eclipse Foundation será capaz de se referir aos originais.

Além disso, curiosamente, a Eclipse Foundation não pode criar nenhum novo pacote Java usando o namespacejavax, mas pode criar novas classes e subclasses sob as existentes.

A transição também significaa new process for adding specifications para Jakarta EE. Para entender melhor,let’s take a look at what that process was like under Oracle and how it changes under the Eclipse Foundation.

No passado, o processo pelo qual um novo recurso de EE nasceu era chamado de Java Community Process (JCP).

O Java SE ainda usa o JCP hoje. Mas, como o EE mudou de propriedade, do Oracle para o Eclipse Foundation, temos um processo novo e separado para isso. É o processo de especificação da Eclipse Foundation (EFSP) e é uma extensão doEclipse Development Process.

Existemsome important differences, porém, principalmente em torno de “Transparência, Abertura, Encargos Compartilhados e Neutralidade do Fornecedor”. Os organizadores do EFSP, por exemplo, imaginam grupos de trabalho colaborativos que são neutros em relação aos fornecedores, um processo de certificação de autoatendimento e uma organização que opera e governa como uma meritocracia.

No JCP, a primeira etapa para adicionar um recurso ao EE foi criar um JSR ou Java Specification Request. The JSR was a bit like the interface for an EE feature. O Comitê Executivo do JCP analisou e aprovou um JSR concluído e, em seguida, os colaboradores do JSR o codificariam e disponibilizariam para a comunidade.

Um bom exemplo disso foiJSR-339 - ouJAX-RS - que foi originalmente proposto em 2011, aprovado pelo JCP em 2012 e finalmente lançado em 2013.

E embora a comunidade sempre pudesse opinar enquanto uma especificação estava em discussão, o tempo mostrou que uma abordagem de implementação - como no caso deJSR 310,java.time, andJoda Time - tendia a criar mais recursos e APIs amplamente aceitos.

Portanto, o EFSP reflete essa visão do código primeiro em seu objetivo declarado: "O EFSP será baseado em experimentação prática e codificação primeiro, como uma maneira de provar que algo é digno de ser documentado em uma especificação".

Então, como parte do JCP, um JSR precisava de uma implementação de referência. This is a bit like the class that implements the interface. Uma implementação de referência ajuda os desenvolvedores de bibliotecas compatíveis ou outras organizações que desejam criar sua própria implementação da especificação.

Para os recursos Java EE, o JCP usou o Glassfish para suas implementações de referência.

E enquanto essa centralização no Glassfish simplificava o processo de descoberta para implementadores, essa centralização também exigia mais governança e tendia a favorecer um fornecedor em detrimento de outro.

Portanto, o EFSP não requer uma implementação de referência, mas apenas uma simplificaçãocompatible . Simplificando, essa mudança sutil faz com queimplementations inside of a central architecture, like Glassfish, won’t be inadvertently preferred by the foundation.

Por fim, o JCP exigia que os recursos de EE fossem testados por meio do Kit de compatibilidade de tecnologia ouTCK.

O TCK era um conjunto de testes para validar um EE JSR específico. Simplificando,in order to comply with Java EE, an application server needs to implement all of its JSRs and pass all the tests on the designated TCK.

Não há muitas mudanças aqui. A Oracle forneceu o TCK e os EE JSRs de código aberto. Obviamente, todos os documentos futuros e o TCK serão de código aberto.