Após seis meses de desenvolvimento, a Oracle lançou a plataforma Java SE 26 (Java Platform, Standard Edition 26), da qual a implementação de referência utiliza o projeto aberto OpenJDK. Exceto pela remoção de algumas funcionalidades obsoletas, a compatibilidade retroativa com versões anteriores da plataforma Java foi mantida no Java SE 26 – a maioria dos projetos Java escritos anteriormente funcionará sem alterações na nova versão. As compilações prontas para instalação do Java SE 26 (JDK, JRE e Server JRE) estão disponíveis para Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). A implementação de referência do Java SE 26, desenvolvida como parte do projeto OpenJDK, é totalmente aberta sob a licença GPLv2, com exceções do GNU ClassPath que permitem a vinculação dinâmica a produtos comerciais.
O Java SE 26 é classificado como uma versão com suporte regular, com atualizações sendo lançadas até o próximo lançamento. As versões com suporte de longo prazo (LTS) recomendadas incluem Java SE 25, Java SE 21 ou Java SE 17, cujas atualizações serão disponibilizadas até 2033, 2031 e 2029, respectivamente (públicas até setembro de 2030, 2028 e 2026). O suporte estendido para a versão LTS do Java SE 8 se estenderá até 2030, enquanto o Java SE 11 terá suporte até 2032.
As mudanças no Java SE 26 (1, 2, 3, 4):
- Foi implementado um aviso ao usar reflexão profunda para modificar campos marcados com a palavra-chave 'final'. No futuro, estão planejadas desativações padrão de recursos inseguros da linguagem e, entre outras mudanças, os campos marcados como final se tornarão completamente imutáveis, removendo os caminhos alternativos para sua modificação através da reflexão profunda (API Reflection).
- A API Applet (java.applet.Applet*, javax.swing.JApplet) foi removida, a qual era utilizada para executar aplicativos Java em navegadores. Essa API tornou-se obsoleta após o fim do suporte ao plugin Java para navegadores e foi declarada obsoleta em 2021.
- Foi implementada a possibilidade de usar cache pré-formatado (AOT — ahead-of-time) com qualquer coletor de lixo, incluindo o ZGC (Z Garbage Collector). A alteração implica suporte para o carregamento sequencial de objetos Java em cache na memória, utilizando um formato genérico e independente do coletor de lixo em vez de mapeamento direto para representações específicas de cache na memória. O uso do cache AOT reduz o tempo de inicialização e acelera a atualização (warmup) da máquina virtual HotSpot.
- Na API HTTP Client, foi adicionada a compatibilidade com o protocolo HTTP/3, permitindo que aplicativos e bibliotecas acessem servidores via HTTP/3 após alterações mínimas no código.
- Aumentou-se o desempenho do coletor de lixo G1, graças à redução de bloqueios para sincronização entre threads de aplicativo e threads do coletor de lixo.
- Um segundo pré-lançamento da API foi proposto para codificação e decodificação de objetos com chaves criptográficas, certificados e listas de certificados revogados, utilizando o formato PEM (Pivacy-Enhanced Mail).
- Foi proposto para testes o sexto pré-lançamento da API de concorrência estruturada (Structured Concurrency), simplificando o desenvolvimento de aplicativos multithread ao tratar várias tarefas executadas em diferentes threads como um único bloco.
- Adicionou-se a segunda prévia da API Lazy Constants para trabalhar com objetos que contêm dados imutáveis e são tratados na JVM como constantes. A esses objetos são aplicadas otimizações de desempenho semelhantes aos campos com a palavra-chave 'final'. Diferente de 'final', a nova API separa a criação de valores constantes da sua inicialização, garantindo que o valor possa ser inicializado apenas uma vez, reduzindo o tempo de inicialização dos programas e permitindo a aplicação de otimizações de redução de constantes (constant-folding) no código do usuário, anteriormente utilizadas apenas no código interno do JDK. class Application { // Antes: // static final UserService USERS = new UserService(); // Agora pode-se: static final StableValue<UserService> USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
- No mecanismo de correspondência de padrões, foi proposta uma quarta opção preliminar para o uso de tipos primitivos (int, byte, char e outros tipos base que não são objetos) em todos os tipos de templates, na operação «instanceof» e em blocos «switch». switch (x.getStatus()) { case 0 -> «ok»; case 1 -> «aviso»; case 2 -> «erro»; case int i -> «status desconhecido: » + i; } if (i instanceof byte b) { … b … }
- Foi proposta uma décima primeira implementação de teste da API Vector, que fornece funções para cálculos vetoriais realizados usando instruções vetoriais dos processadores x86_64 e AArch64, permitindo aplicar operações simultaneamente a vários valores (SIMD). Diferentemente das capacidades de vetorização automática de operações escalares oferecidas pelo compilador JIT HotSpot, a nova API oferece a possibilidade de gerenciar explicitamente a vetorização para processamento paralelo de dados.
Além disso, a Oracle anunciou o projeto Detroit, que se desenvolverá dentro do OpenJDK e visa melhorar a portabilidade entre Java, JavaScript e Python. No âmbito do projeto, pretende-se oferecer a capacidade de incorporação no runtime da JVM com o motor JavaScript V8 e o interpretador CPython. Anteriormente, a Oracle havia desenvolvido o motor JavaScript Nashorn, que funcionava sobre a máquina virtual JVM, mas interrompeu o projeto devido à dificuldade de desenvolver uma implementação separada do JavaScript em um contexto em que o ecossistema principal é baseado no motor V8.
Adicionalmente, podemos notar a publicação da atualização da plataforma para a criação de aplicativos com a interface gráfica JavaFX 26. Nas próximas horas, também se espera o lançamento da máquina virtual universal GraalVM 26, que suporta a execução de aplicativos em JavaScript (Node.js), Python, Ruby, R, quaisquer idiomas para JVM (Java, Scala, Clojure, Kotlin) e idiomas para os quais pode ser gerado código bitcode LLVM (C, C++, Rust).
Fonte: opennet.ru
