O gigante acordou: Jakarta EE 11 moderniza o Java para empresas

O universo do desenvolvimento Java empresarial acaba de receber um upgrade de peso. O Jakarta EE 11 finalmente está entre nós, marcando uma evolução significativa para a plataforma que sucedeu o antigo Java EE. De acordo com o anúncio oficial detalhado pelo portal InfoQ, esta versão chega para simplificar a vida dos desenvolvedores e turbinar o desempenho das aplicações, alinhando o ecossistema com as inovações mais recentes do Java SE, como os aguardados records e as threads virtuais.

A plataforma, que é a espinha dorsal de frameworks populares como Spring, Quarkus e Payara, lança mão de atualizações em 16 especificações e introduz um componente totalmente novo: o Jakarta Data. Este lançamento estabelece o Java 17 como requisito mínimo e oferece suporte completo ao Java 21, abrindo as portas para um desenvolvimento mais moderno e eficiente.

Atrasou, mas foi por um bom motivo

Para os mais ansiosos, a espera pelo Jakarta EE 11 pareceu longa. Conforme explicado pelo Jakarta EE Working Group, o atraso foi estratégico e teve um propósito nobre: modernizar o Technology Compatibility Kit (TCK). Pense no TCK como o rigoroso controle de qualidade da plataforma. A decisão de investir tempo para atualizá-lo, migrando de tecnologias como Ant para Maven e de TestHarness para Arquillian, foi como arrumar a fundação da casa antes de construir novos andares. Essa reforma interna, embora invisível para o usuário final, garante testes de compatibilidade mais robustos e facilita a evolução futura do ecossistema.

Além da faxina no TCK, a versão 11 também fez uma limpeza em seu core. O antigo Jakarta Managed Beans foi aposentado em favor das alternativas mais modernas do CDI (Contexts and Dependency Injection). Referências ao Security Manager, obsoleto desde o Java 17, foram removidas, assim como funcionalidades opcionais como Jakarta SOAP with Attachments, simplificando a plataforma para novos fornecedores e desenvolvedores.

As novidades que importam: Dados, Records e Threads

O grande destaque do Jakarta EE 11 é, sem dúvida, a introdução do Jakarta Data. Para quem já está familiarizado com o Spring Data, a proposta soa familiar: facilitar o acesso a bancos de dados, sejam eles SQL ou NoSQL, através de uma interface unificada. Com o Jakarta Data, desenvolvedores podem criar repositórios de dados com pouquíssimo código. A especificação permite gerar consultas de três formas: por convenção de nomenclatura de métodos, com a anotação @Find ou usando a Jakarta Data Query Language (JDQL), um subconjunto da JPQL. Tarefas complexas como paginação também foram drasticamente simplificadas.

O suporte ao Java 17 e 21 trouxe duas das funcionalidades mais celebradas do Java moderno para o mundo empresarial:

• Java Records: Agora é possível usar Records como classes embutidas (@Embeddable) e como IDs compostos no Jakarta Persistence, tornando o código para estruturas imutáveis, como um endereço ou uma chave primária composta, muito mais limpo e conciso. A fonte do InfoQ ressalta, no entanto, que o suporte ainda não se estende para usar Records como entidades completas.
• Threads Virtuais: O ganho de desempenho em aplicações concorrentes ficou absurdamente simples. A especificação Jakarta Concurrency agora permite habilitar threads virtuais com a mudança de um único atributo booleano. Ao definir um executor gerenciado, basta adicionar virtual = true na anotação @ManagedExecutorDefinition e a aplicação passará a usar threads virtuais, otimizando o uso de recursos em cenários de alta concorrência.

Java também aprendeu a ser 'preguiçoso' (no bom sentido)

Paralelamente às novidades do Jakarta EE, o próprio núcleo do Java continua sua marcha evolutiva. Conforme detalhado em um artigo do Inside.java, a JEP 502, uma funcionalidade em preview no JDK 25, introduz os "Stable Values". Na prática, é uma forma otimizada e padronizada de implementar computação preguiçosa (lazy computation). Isso permite que um valor seja calculado apenas no momento em que é realmente necessário, e o compilador JIT do HotSpot pode otimizar esse processo a ponto de substituir a chamada por uma constante, garantindo um ganho de performance notável.

Uma curiosidade apontada no artigo é por que a feature se chama "Stable" (estável) e não simplesmente "Lazy" (preguiçoso). A resposta é que as propriedades de um campo "estável" são um superconjunto das de um campo "preguiçoso". Um valor estável é calculado no máximo uma vez, garantindo consistência, e pode até ser pré-calculado em cenários específicos, algo que o termo "lazy" não cobriria completamente.

O futuro já bate à porta: Vem aí o Jakarta EE 12

Mal o Jakarta EE 11 foi lançado e os planos para a próxima versão já estão em andamento. Segundo Ivar Grimstad, Developer Advocate da Eclipse Foundation, o Jakarta EE 12 já tem um rascunho de plano e uma data de lançamento prevista para julho de 2026. A InfoQ destaca que o grande tema da próxima versão será a "Idade dos Dados".

Gavin King, criador do Hibernate, manifestou seu entusiasmo com o futuro da persistência na plataforma. O plano para o Jakarta EE 12 é ambicioso e inclui a integração do Jakarta NoSQL 1.1 diretamente na plataforma, consolidando o suporte à persistência poliglota. Além disso, uma nova especificação, a Jakarta Query, será criada com o objetivo de unificar a linguagem de consulta entre Jakarta Persistence, Jakarta Data e Jakarta NoSQL. Essa é uma jogada estratégica para criar um ecossistema de dados coeso e poderoso.

Em suma, o Jakarta EE 11 não é apenas uma atualização, mas uma declaração de intenções. A plataforma está se modernizando, abraçando as melhores características do Java recente e pavimentando um caminho claro para um futuro onde o desenvolvimento empresarial será mais produtivo, performático e preparado para a diversidade de bancos de dados do mundo moderno.