Lançamento do Java SE 24 e OpenJDK 24

Após seis meses de desenvolvimento, a Oracle lançou a plataforma Java SE 24 (Java Platform, Standard Edition 24), cuja implementação de referência é o projeto aberto OpenJDK. Exceto pela remoção de algumas funcionalidades obsoletas, a Java SE 24 mantém a compatibilidade retroativa com as versões anteriores da plataforma Java — 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 24 (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 da Java SE 24, desenvolvida dentro do projeto OpenJDK, é completamente aberta sob a licença GPLv2 com exceções do GNU ClassPath, permitindo vinculação dinâmica com produtos comerciais.

A Java SE 24 é classificada como uma versão com suporte normal, cuas atualizações serão lançadas até o próximo lançamento. Para uma ramificação de longo prazo (LTS), devem ser usadas a Java SE 21 ou a Java SE 17, cuas atualizações serão disponibilizadas até 2031 e 2029, respectivamente (públicas até 2028 e 2026). O suporte estendido da ramificação LTS da Java SE 8 continuará até 2030, enquanto a Java SE 11 terá suporte até 2032. O próximo lançamento LTS será a versão de outono da Java SE 25.

Entre as novidades da Java SE 24 estão:

• Foi introduzido um modo experimental generativo para o coletor de lixo Shenandoah, onde objetos antigos e recém-criados são processados separadamente para melhorar a eficiência da limpeza de objetos com curta duração de vida. O novo modo fornece maior previsibilidade de throughput, resistência a mudanças de carga e redução do consumo de memória durante a coleta de lixo. O planejador Shenandoah visa reduzir o tempo de pausas durante a coleta de lixo realizando uma maior quantidade de trabalho em paralelo com a execução de aplicativos Java.
• Na HotSpot JVM, foi implementado suporte experimental para cabeçalhos compactos de objetos, cujo tamanho em sistemas de 64 bits foi reduzido de 96 para 64 bits (de 12 para 8 bytes). A redução no tamanho dos cabeçalhos permite diminuir o tamanho do heap e aumentar a eficiência do cache.
• No coletor de lixo G1, a implementação de barreiras que monitoram o acesso do aplicativo à memória foi simplificada. Na nova versão, as operações de expansão das barreiras foram transferidas para uma fase posterior da compilação no JIT C2. Testes realizados mostram que essa transferência permite reduzir a sobrecarga no compilador JIT C2 em 10-20%, dependendo do aplicativo.
• Adicionado API para utilizar funções criptográficas de derivação de chave (KDF, key derivation function), permitindo gerar chaves adicionais de comprimento necessário com base em uma chave secreta (como uma senha) e um conjunto de dados arbitrário. O API KDF ainda está em status de pré-visualização (preview).
• Adicionada a capacidade de carregamento e organização de classes antecipadas (Ahead-of-Time). Essa alteração acelera o início da HotSpot JVM ao fornecer as classes usadas no aplicativo já carregadas e organizadas. Durante a primeira execução do aplicativo, o estado de todas as classes é armazenado em cache e, em execuções subsequentes, é usado para acelerar o carregamento.
• Adicionado API Class-File para análise, geração e transformação de arquivos com classes Java.

  ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith(«debug»))) { classBuilder.with(ce); } } });

• Adicionado API Stream avançado, suportando a definição de operações intermediárias personalizadas, que podem ser úteis quando as operações intermediárias integradas existentes não são suficientes para a transformação de dados desejada. Manipuladores personalizados são conectados por meio de uma nova operação intermediária Stream::gather(Gatherer), que processa os elementos do fluxo aplicando a eles o manipulador especificado pelo usuário. jshell> Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
• Foi proposta a quarta implementação preliminar de Scoped Values, permitindo o compartilhamento de dados imutáveis em fluxos e a troca eficiente de dados entre fluxos filhos (os valores são herdados). Scoped Values estão sendo desenvolvidas para substituir o mecanismo de variáveis locais para o fluxo (thread-local variables) e são mais eficientes ao utilizar um número muito grande de fluxos virtuais (milhares e milhões de fluxos). A principal diferença entre Scoped Values e variáveis locais do fluxo é que as primeiras são gravadas uma vez, não podem ser alteradas posteriormente e permanecem disponíveis apenas durante a execução do fluxo.
• A mecânica de correspondência de padrões foi adicionada à pré-suporte para o uso de tipos primitivos (int, byte, char e outros tipos básicos que não são objetos) em todos os tipos de padrões, no operador «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 a nona implementação preliminar da API Vector, que fornece funções para cálculos vetoriais executados usando instruções vetoriais dos processadores x86_64 e AArch64, permitindo aplicar operações a vários valores ao mesmo tempo (SIMD). Ao contrário das capacidades de auto-vetorização de operações escalares fornecidas pelo compilador JIT HotSpot, a nova API permite um controle explícito da vetorização para o processamento paralelo de dados.
• Foi implementado o suporte à sincronização de fluxos virtuais sem vinculá-los (pinning) a fluxos relacionados à plataforma. Fluxos virtuais em métodos ou expressões sincronizadas em estado de bloqueio agora liberam seu fluxo de plataforma, permitindo que outros fluxos virtuais o utilizem, o que aumenta significativamente o número de fluxos virtuais disponíveis e melhora a escalabilidade de aplicativos que utilizam multithreading.
• Adicionada a terceira versão preliminar de um recurso que permite a especificação em construtores de expressões antes da chamada de super(...), utilizada para chamar explicitamente o construtor da classe pai a partir do construtor da classe herdada, se essas expressões não se referirem à instância criada pelo construtor. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
• A ferramenta jlink agora suporta a criação de imagens em tempo de execução sem o uso de arquivos JMOD, o que permite uma redução de cerca de 25% no tamanho do JDK.
• Adicionada a segunda versão preliminar do uso de uma expressão "import module M" para importar todos os pacotes exportados pelo módulo especificado de uma só vez. Essa mudança simplifica significativamente o reaproveitamento de bibliotecas modulares, permitindo a inclusão de bibliotecas e classes sem a necessidade de definir sua localização na hierarquia de pacotes. Por exemplo, especificar "import module java.base" resultará na importação de todos os 54 pacotes que compõem o módulo java.base, que anteriormente precisariam ser mencionados separadamente ("import java.io.*", "import java.util.*", etc.).
• Adicionada a quarta implementação preliminar de classes implicitamente declaradas e instâncias anônimas do método "main", onde é possível prescindir de declarações public/static, passagem de arrays de argumentos e outras entidades relacionadas à declaração da classe. // antes public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // agora pode-se void main() { System.out.println("Hello, World!"); }
• Proposto para teste um quarto variante preliminar da API para concorrência estruturada (Structured Concurrency), que simplifica o desenvolvimento de aplicações multithread ao tratar várias tarefas executadas em diferentes threads como um único bloco.
• Na API KeyPairGenerator, Signature e KeyFactory, foi adicionada a suporte a algoritmos ML-KEM (CRYSTALS-Kyber) e ML-DSA (CRYSTALS-Dilithium), padronizados pelo Instituto Nacional de Padrões e Tecnologia dos EUA (NIST) e resistentes a ataques por computadores quânticos. Esses algoritmos utilizam métodos criptográficos baseados na resolução de problemas da teoria de redes, cujo tempo de solução não difere em computadores convencionais e quânticos.
• No coletor de lixo ZGC, o suporte para o modo de operação não gerador, que não separa o processamento de objetos 'velhos' e 'jovens', foi removido. A partir do Java SE 23, o modo gerador do ZGC é aplicado por padrão.
• Adicionada a emissão de avisos sobre o uso da API JNI (Java Native Interface) e FFM (Foreign Function & Memory) com o objetivo de preparar os desenvolvedores para a restrição do acesso a essas APIs devido à inclusão, em uma das futuras versões, do modo de integridade, que por padrão proíbe a interação com código nativo.
• Foi incluída a emissão de um aviso ao usar métodos de acesso à memória externa (fora da JVM), fornecidos pela classe sun.misc.Unsafe. Para acessar a memória fora da heap (off-heap) e interagir com código externo, recomenda-se usar a API VarHandle. Na versão anterior, o suporte ao sun.misc.Unsafe foi declarado obsoleto.
• O Security Manager foi desativado, já que há muito perdeu a relevância e se tornou desnecessário após o fim do suporte ao plugin de navegador. O Security Manager foi classificado como obsoleto no Java 17. Em uma das próximas versões, está previsto a remoção total do código do Security Manager.
• O código de suporte à plataforma Windows de 32 bits em sistemas x86 foi removido. O port para sistemas x86 de 32 bits foi declarado obsoleto e está programado para remoção (o suporte ao Linux para sistemas x86 de 32 bits será descontinuado).

Além disso, pode-se destacar a publicação da atualização da plataforma para construção de aplicações JavaFX 24 e uma nova versão da Máquina Virtual Universal GraalVM, que suporta a execução de aplicativos em JavaScript (Node.js), Python, Ruby, R, quaisquer linguagens para JVM (Java, Scala, Clojure, Kotlin) e linguagens que podem gerar código de byte LLVM (C, C++, Rust). Além do suporte ao JDK 24, a nova versão da GraalVM trouxe otimizações para tarefas relacionadas a aprendizado de máquina, melhor suporte à compilação de bytecode Java para código de máquina, e um mecanismo SkipFlow foi adicionado para reduzir o tamanho dos arquivos executáveis e diminuir o tempo de compilação.

Fonte: opennet.ru