Pular para o conteúdo principal

Jakarta EE 9.1 foi lançado

Nesta semana, a Eclipse Foundation anunciou o lançamento da nova versão do Jakarta EE, a versão 9.1. O objetivo dessa versão foi tornar a plataforma Jakarta EE totalmente compatível com o Java SE 11. Importante frisar que foi mantida total compatibilidade com o Java SE 8.

Vale aqui uma boa contextualização, para quem não tem acompanhado as notícias do mundo Java. O pessoal das antigas vai lembrar da diferenciação entre Java SE (Standard Edition, o Java que sempre instalamos no computador) e Java EE (Enterprise Edition, um conjunto de especificações que eram implementadas por servidores de aplicação). Essas plataformas eram controladas pela Sun, e passaram a ser controladas pela Oracle, quando esta última comprou a primeira.

A plataforma Java SE viu uma evolução tremenda nos últimos anos. O ritmo de lançamento das novas versões passou a ser semestral, com pequenos avanços em cada versão. Assim, o Java SE agora se encontra na versão 16, com expectativa de lançamento da versão 17 em setembro (as novas versões são lançadas nos meses de março e setembro de cada ano). Foram instituídas também as chamadas versões LTS (Long Term Support), sendo a mais atual nesse sentido a versão 11 (por isso o interesse da Eclipse Foundation em fazer a nova versão do Jakarta EE compatível com o Java 11, a versão LTS mais atual do Java SE).

Já no mundo Java EE, a evolução era lenta e muito controlada pela Oracle. A comunidade reclamava e pressionava por um processo mais aberto. Logo após o lançamento da versão 8, a Oracle decidiu ceder para a comunidade o controle, que acabou sendo transferido para a Eclipse Foundation (sim, a mesma que desenvolve a IDE, mas que também toca inúmeros outros projetos importantes). Não sem antes criar alguma confusão: eles mantiveram o controle de propriedade intelectual na marca Java, o que, na prática, impedia a evolução das especificações sem uma mudança drástica (mais sobre essa mudança já já).

A primeira versão da plataforma Jakarta EE lançada pela Eclipse Foundation foi a versão 8, que era totalmente compatível com a versão 8 do Java EE. Um lançamento mais ou menos simbólico, eu diria. Aconteceu em setembro de 2019. A mudança drástica que falei no parágrafo anterior ficou para a próxima versão.

A mudança drástica veio com a versão 9 da plataforma, lançada em novembro de 2020. Consistiu na mudança do nome de todos os pacotes relativos às especificações. Todo pacote que se chamava javax.*, na nova versão 9 agora se chama jarkarta.*. Exemplo: as classes, interfaces e anotações da JPA, agora chamada de Jakarta Persistence, ficam no pacote jakarta.persistence.*. E esta nova versão já está sendo implementada por diversos produtos: IBM Open Liberty, Eclipse Glassfish, Red Hat Wildfly, dentre outros.

Percebam o trabalho que teremos para migrar nossas aplicações para esta plataforma - mudar todos os imports relativos ao Java EE. Claro que é algo apenas trabalhoso, sem muita complexidade, entretanto um trabalho relevante. Porém, algo importante para a comunidade, que se torna totalmente independente do controle da Oracle e suas marcas registradas, e pode ditar o ritmo desejado de inovação na plataforma. Esse lançamento da versão 9.1 aponta para um ritmo interessante, com versões major anuais e algumas versões minor pelo caminho. Um ritmo necessário para a plataforma Jakarta EE recuperar o tempo perdido e buscar a inovação que tantos sempre desejaram.

Um abraço e até o próximo post!


Comentários

Postagens mais visitadas deste blog

Jakarta EE 10, A nova versão corporativa do Java

Mais de um ano atrás, fiz um post sobre o lançamento da versão 9.1 do Jakarta EE (confira esse post aqui ). Nesse post, eu expliquei um pouco sobre a transferência do Java EE da Oracle para a Eclipse Foundation e a mudança necessária ocorrida nessa versão no nome dos pacotes: de javax para jakarta . Agora, acabou de sair uma nova versão do Jakarta EE , versão 10 , a primeira versão que verdadeiramente traz novidades nas especificações que tanto conhecemos: JPA agora evoluiu para a versão 3.1; CDI para a versão 4.0; JAX-RS  para a versão 3.1; e assim por diante. Foram mais de vinte especificações atualizadas / evoluídas nesta versão, que criou também um novo perfil de implementação. Agora, temos três perfis para implementação do Jakarta EE :  Jakarta EE 10 Platform , o perfil completo com todas as especificações (este perfil somente os servidores de aplicação costumam implementar, como Wildfly e Glassfish ); Jakarta EE 10 Web Profile , um perfil com especificações volta...

Maven - Versão nova lançada

  Saiu versão nova do Maven - 3.8.2. Esta foi apenas uma versão de correção de bugs, mas a versão anterior, a 3.8.l, foi uma versão importante e vou aproveitar para falar sobre ela. Quem acompanha o histórico de versões do Maven , deve ter percebido o pulo de versão, da 3.6.3 para esta 3.8.1. A razão está explicada neste link , e o grande motivo foi tentar evitar problemas de segurança pelo acesso a repositórios via protocolo HTTP. Por default, esta versão 3.8.1 do Maven bloqueia o acesso a repositórios HTTP - você precisa acessar repositórios HTTPS . O bloqueio acontece com a adição de um mirror chamado "maven-default-http-blocker", bloqueando todo e qualquer acesso a repositórios HTTP externos. <mirror>    <id>maven-default-http-blocker</id>    <mirrorOf>external:http:*</mirrorOf>   <name>Pseudo repository to mirror external repositories initially using HTTP.</name>    <url>http://0.0.0.0/</u...

Implantando o Flyway em sistemas Java - Parte 1

  Quando temos uma empresa terceirizada de fábrica de software desenvolvendo, geralmente especificamos no edital de licitação que essa empresa precisa entregar alguns artefatos obrigatórios para poder receber pelos serviços prestados: o código-fonte (óbvio!), diagramas UML (quando necessário), evidências de testes (artefato que cada vez mais me convenço que de nada serve)... e um plano de implantação. Esse plano de implantação precisa trazer os passos necessários para colocar o produto no ambiente de homologação (e, posteriormente, no ambiente de produção). Na maioria das vezes, um ou mais scripts de banco de dados que devem ser executados. Nós, servidores, tínhamos que abrir o plano de implantação, verificar os passos, acessar o versionador, abrir a ferramenta de banco de dados, copiar o(s) script(s), executá-los, tudo manualmente, gerando um trabalhinho chato e propenso a erros. Além disso, os scripts sempre ficavam meio perdidos: as vezes espalhados por pastas relativas às orden...