Pular para o conteúdo principal

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 voltadas para implementação de sistemas Web, incluindo padrões para persistência, transações, JSF e outros (o Tomcat costuma implementar parte desse perfil);
  • O novo perfil Jakarta EE 10 Core Profile, um perfil mais enxuto que procura incluir as especificações voltadas para implementação de serviços RESTFul, incluindo uma versão simplificada do CDI, a CDILite.

As especificações de cada perfil do Jakarta EE 10

Algumas poucas novidades das novas especificações:

  • Jakarta RESTful Web Services 3.1 - padronização de uma API para bootstrap no Java SE e padronização dos dados de formulário multipart, uma funcionalidade que era pedida faz tempo na especificação;
  • Jakarta Persistence 3.1 - trazendo suporte ao tipo de dados java.util.UUID e adição de diversas funções à linguagem de query (JPQL);
  • Jakarta Security 3.0 - trazendo suporte ao padrão OpenID Connect;
  • CDI Lite - uma versão mais enxuta da especificação CDI 4.0, permitindo a utilização da especificação em ambientes mais restritos de recursos.

Percebemos que a comunidade Java está antenada com as tendências de nuvem e serviços REST, arquitetura MicroProfile e outros, procurando evoluir a plataforma Jakarta EE nessa direção. Resta agora aguardar que os grandes nomes do mercado evoluam seus produtos e implementem essa nova versão das especificações - até agora, somente a implementação padrão, Eclipse Glassfish, e versões alpha do Payara e Wildfly.

Reveja seus conceitos e venha acompanhar as novidades da plataforma Java, evoluindo cada vez mais!!

Comentários

Postagens mais visitadas deste blog

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...