Jakarta EE, o futuro do Java EE

Estamos passando por uma nova transição dentro do Java: a Oracle, detentora dos direitos sobre a linguagem, cedeu o Java EE para a Eclipse Foundation. A marca Eclipse, se assim podemos chamá-la, é bastante conhecida devido a IDE Eclipse, idealizada e doada pela IBM em 2001 a um consórcio formado por importantes empresas que apoiaram o desenvolvido da IDE e deram sequência ao projeto inicial. Apenas em 2004 nasce a Eclipse Foundation, uma fundação sem fins lucrativos, mas como uma hierarquia bem definida, possibilitando que novos parceiros chegassem e apoiassem os atuais e futuros projetos.

Mas qual a importância, significado e objetivos dessa transição? Será algo positivo ou negativo para o futuro do desenvolvimento Java na web? Perguntas como estas estão sendo feitas a todo instante, porém as respostas são confusas e incompletas. Muitos não conseguem compreender essa transição porque na verdade não sabem realmente o que significa o Java EE. Sendo assim, antes de começarmos a analisar a transição do Java EE para o Jakarta EE é importante esclarecer o que é o Java EE e como ele surgiu.

O caminho até o Java EE

A linguagem Java foi lançada em meados dos anos 90, uma época em que a internet ainda era muito embrionária e as aplicações desktop dominavam. Entretanto, ano após ano a internet mostrava crescimento e enquanto isso a Sun Microsystems, proprietária do Java, idealizou o primeiro projeto para Java corporativo, nomeado de J2EE (Java 2 Platform, Enterprise Edition).

Saiba mais: Guia de Java EE

O J2EE 1.2 foi lançado oficialmente em dezembro de 1999 e começava nesse momento os primeiros passos do Java também no mundo web. A ideia da Sun foi criar um projeto guarda-chuva para especificações detalhadas com foco no desenvolvimento de sistemas corporativos, reduzindo assim os custos e a complexidade de sistemas multicamadas. Para isso, o J2EE foi definido como uma arquitetura baseada em quatro elementos, que são:

• J2EE Platform – uma plataforma padrão, que segue as especificações de um conjunto de APIs para a hospedagem de aplicativos J2EE;
• J2EE Compatibility Test Suite – conjunto de testes de compatibilidade que verifica se um produto da plataforma J2EE é compatível com o padrão e especificações da J2EE;
• J2EE Reference Implementation – uma implementação de referência que demonstre os recursos do J2EE como demonstração e definição operacional da Plataforma J2EE;
• Sun Blueprints Design Guidelines for J2EE – diretrizes que descrevem um modelo de programação padrão para o desenvolvimento de aplicativos multicamadas.

Analisando os quatro elementos citados, podemos destacar algumas palavras chaves como especificação e padrão e elas são muito importantes para se entender o que realmente é o J2EE.

O objetivo do J2EE era desenvolver um sistema de APIs (Application Programming Interface), especificando assim um padrão para o desenvolvimento de implementações. Desta forma, poderiam surgir implementações de código aberto ou mesmo proprietárias, abrindo um maior leque de possibilidades para o desenvolvimento de sistemas corporativos. Uma API é basicamente uma biblioteca formada por interfaces. Essas interfaces precisam ser implementadas com métodos que executem tais funcionalidades.

A função da especificação (API) é fornecer portabilidade entre diferentes implementações. Nos últimos anos, uma API bastante conhecida é a JPA e suas implementações são, por exemplo, o Hibernate Framework, EclipseLink, OpenJPA e Oracle TopLink. Outra API que podemos citar é a Java Server Faces (JSF) com as implementações Mojarra, MyFaces e Oracle ADF Faces.

Em 1999, algumas das APIs que fizeram parte da versão J2EE 1.2 foram: Enterprise JavaBeans (EJB), JavaServer Pages (JSP), Java Servlet, Java Naming and Directory Interface (JNDI), Java Database Connectivity (JDBC), JavaMail, Java Transaction (JTA).

A Sun continuou renovando e aprimorando o J2EE e assim foram lançadas as versões 1.3 em Setembro de 2001 e 1.4 em Novembro de 2003. Com a aquisição da Sun Microsystems pela Oracle a nova versão do J2EE, que seria a 1.5, acabou sendo lançada como Java EE 5 em Maio de 2006. Começa nesse momento a história do Java EE, que não é nada mais nada menos que uma continuidade ao J2EE com uma renomeação. Novas versões, atualizando e incluindo novos recursos, foram lançadas pelas Oracle como o Java EE 6 em Dezembro de 2009, Java EE 7 em Abril de 2013 e por fim o Java EE 8 em Agosto de 2017.

J2EE Containers

Um dos quatro elementos da arquitetura J2EE era a plataforma de hospedagem para os aplicativos J2EE. Essa plataforma, também conhecida como servidores, foi baseada em dois containers. Esses containers servem para o armazenamento de dois tipos distintos de aplicações web Java, são eles:

• Web Container – tem como objetivo executar e controlar a execução dos Servlets, JSP e Java Expression Language (e atualmente Java Web Socktes);
• EJB Container – é responsável por executar e controlar aplicações baseadas em EJB.

Entre os servidores temos, como exemplo, o Apache Tomcat como um Web Container que implementa algumas especificações tais quais a Java Servlet, JSP, JDBC e JNDI. E como EJB Container temos o Glassfish, que implementa todas as especificações J2EE/JEE.

O Glassfish, por ser um servidor desenvolvido pela Sun e depois passado a Oracle, serve também como a plataforma J2EE/JEE de referência, terceiro elemento na lista dos quatro elementos da arquitetura J2EE. A referência serve como um modelo para a implementação das especificações, o qual pode ser usado por outros servidores queiram segui-las.

API, Implementação de Referência e JCP

A idealização do J2EE pela Sun Microsystems foi algo muito bem elaborada. A Sun criou um órgão nomeado de JCP (Java Community Process) para selecionar, gerenciar e aprovar projetos que se tornariam uma especificação. Esse órgão é composto por empresas e pessoas que provam estar ligadas a projetos Java e podem contribuir com o crescimento e aprimoramento da linguagem.

Quando uma API é enviada para análise e aprovada para fazer parte do J2EE/JEE ou mesmo J2SE/JSE ela recebe um código iniciado com a sigla JSR (Java Specification Request) seguido por um número. Esse código é o identificador da especificação, como exemplo, podemos citar alguns: JSR-53 para Servlet 2.3 e JSP 1.2; JSR-54 para a versão 3.0 da API JDBC; JSR-914 para JMS 1.0; JSR-317 para JPA 2.0; entre outras.

Cada JSR precisa de uma implementação e essa deve passar por um processo de certificação, baseado em uma bateria de testes para garantir que todas as normas e padrões foram seguidos. Esse processo é o TCK (Technology Compatibility Kit). Ou seja, para que um servidor de aplicações Java seja certificado que implementa a plataforma JEE é preciso que ele passe nesse processo de testes.

Existem também algumas implementações chamadas de referências, como o Glassfish, entre os servidores J2EE/JEE Full (implementação completa), Mojarra para a especificação do JSF, Jersey para a especificação JAX-RS e JBoss Weld para a especificação de CDI. Esse tipo de implementação serve como um modelo para que outras empresas ou desenvolvedores estudem e criem as suas próprias implementações. Podemos citar entre os servidores o JBoss, Wildfly, WebSphere e WebLogic como implementações da plataforma J2EE/JEE Full. Além disso, é importante que em alguns casos quando uma nova especificação seja lançada, já exista pelo menos uma implementação para que os desenvolvedores possam começar a trabalhar com ela. Por esse motivo, temos as implementações de referência.

Quando a Oracle comprou a Sun Microsystems manteve a continuidade dos processos de desenvolvimento das especificações. O órgão JCP passou a ser comandado dentro da empresa e com o passar dos anos, o interesse e investimentos da Oracle em computação nas nuvens reduziu os investimentos no Java EE. Essas reduções acabaram preocupando muitas das empresas com participação direta no JCP e em demais projetos Java. Enquanto outras linguagens estavam evoluindo o Java EE parecia estar ficando para trás. Após algumas diversas reuniões a Oracle então resolveu doar os direitos da especificação Java EE a Eclipse Foundation. Isso aconteceu em Setembro de 2017. Quando dizemos os direitos, é tudo o que pertencia a plataforma Java EE como códigos fontes, JSRs, TCK e o poder para o surgimento de um novo órgão semelhante ao JCP.

Porém, algo importante a destacar é que Oracle mantém os direitos sobre o nome Java EE, sendo assim, a Eclipse Foundation passou a usar o nome Jakarta EE (Jakarta Eclipse Enterprise).

Do Java EE ao Jakarta EE

Jakarta foi um importante projeto, do tipo guarda-chuva, elaborado pela Apache Foundation. Entre os projetos que faziam parte do Jakarta tínhamos o Apache Tomcat, Struts, Commons, Velocity, Maven, entre vários outros. Entretanto, o Jakarta foi descontinuado em 2011 e os projetos remanescentes se mantiveram separados desde então. Por ter tido uma contribuição importante no mundo Java, o nome Jakarta foi sugerido como substituição ao Java EE e generosamente doado pela Apache Foundation a Eclipse Foundation.

O grande objetivo do Jakarta EE é manter o Java corporativo sempre atual em relação as tendências e demandas do mercado. Evitando assim, que longos e burocráticos processos tomem muito tempo e atrasem o lançamento de atualizações e novas especificações, o que estava acontecendo nos últimos anos sob o comando da Oracle.

Embora a Oracle não seja mais responsável pelo Java EE, a empresa se comprometeu a ter uma participação ativa no futuro do Jakarta EE. Isso é importante porque para você rodar qualquer software baseado em J2EE, Java EE ou Jakarta EE é necessário ter uma máquina virtual Java (JRE) e a Oracle ainda tem os direitos sobre ela.

Outro processo importante que depende diretamente da participação da Oracle é o de migração do então Java EE 8 para a fundação Eclipse. Será a partir do Java EE 8 que o Jakarta EE será desenvolvido. A ideia é lançar o Jakarta EE 8 e para esse processo a Oracle já cedeu alguns projetos importantes como o Grizzly, OpenMQ, Mojarra, JMS, Tyrus, JAX-RS, Jersey, WebSocket API, JSON Processing. Conforme informações serão trinta projetos migrados para a Eclipse Foundation pela Oracle.

Embora o Jakarta EE passe a ser a nova especificação da plataforma EE Java, a marca que comandará os projetos envolvidos foi nomeada como EE4J (Eclipse Enterprise for Java). Ela contemplará o Jakarta EE, o novo órgão EFSP (Eclipse Foundation Specification Process) em substituição ao JCP e também as normas TCK para a certificação das implementações.

Este processo de migração do Java EE para o EE4J foi tão significativo que duas importantes empresas fazem parte do grupo de apoiadores e colaboradores do projeto Jakarta EE, são elas a Microsoft e a Pivotal, esta última, detentora dos direitos sobre o Spring Framework. Além delas, outras grandes empresas de tecnologia são membros do projeto Jakarta EE como a RedHat, IBM, Fujitsu, Cloud Bees, SAP, Vaadin, entre outras.

Conclusão

A principal dúvida entre os desenvolvedores Java era se a migração do Java EE para Jakarta EE poderia ser de alguma forma negativa ao futuro do Java. Na verdade, esta migração talvez seja o grande passo que faltava para que o Java corporativo acompanhe a evolução das tendências na área de desenvolvimento de softwares. Um exemplo de sucesso dentro do mundo Java é o Spring Framework. Cada vez mais adotado por desenvolvedores, está sempre à frente das especificações e acompanhando nas novas tendências. A ideia é que no futuro o Jakarta EE possa seguir o mesmo caminho do Spring.

Um dos objetivos do Jakarta EE é que a cada três meses um novo release seja anunciado, algo muito diferente do que acontecia com o J2EE e Java EE os quais os releases eram lançados no mínimo a cada dois anos. Um dos pontos responsáveis por esse longo período de tempo entre novas versões era a burocracia contida principalmente pelo JCP. Todo o processo de discussão e aprovação de uma nova especificação tomava muito tempo e quando a Oracle assumiu, bem ou mal, ela como proprietária era quem decidia e dava o aval de aprovação. Se uma empresa não está focada 100% no processo, as decisões e aprovações ocorrem de forma muito lenta. Este foi um dos principais motivos para o nascimento do Jakarta EE e será muito importante que se encontre uma forma de agilizar o processo para alcançar o prazo pretendido entre cada nova versão.

Em 28 de janeiro de 2019 o Jakarta EE lançou a primeira versão do GlassFish sob seu comando. O Eclipse GlassFish 5.1 é compatível com o atual Java EE 8 e foi o primeiro projeto concluído no processo de migração entre o Java EE e o Jakarta EE. A promessa é que até meados de 2019 seja anunciada a primeira versão do Jakarta EE, o Jakarta EE 8. Além disso, o Eclipse GlassFish 5.2, quando lançado, será uma implementação de referência compatível com o Jakarta EE.

O futuro para o Java corporativo, ou Java Web como também é muitas vezes citado, parece promissor e o tempo deve provar isso. E você, o que acha, qual a sua opinião sobre essa migração do Java EE para o Jakarta EE?

Mais sobre Java