- A Oracle anunciou oficialmente o lançamento do Java 24 (JDK 24)
- O JDK 24 é a implementação de referência da versão 24 da plataforma Java SE, definida pela JSR 399 do JCP, e foi lançado por meio do processo de lançamento do JDK (JEP 3)
[Resumo por JEP]
-
JEP 404: Generational Shenandoah (experimental)
- Suporte à coleta geracional no Shenandoah GC para melhorar o desempenho
-
JEP 450: Compact Object Headers (experimental)
- Reduz o tamanho do cabeçalho de objetos na HotSpot JVM de 96~128 bits para 64 bits
- Espera-se redução do tamanho do heap, aumento da densidade de implantação e melhoria da localidade de dados
-
JEP 472: Prepare to Restrict the Use of JNI
- Adiciona avisos ao usar JNI (Java Native Interface)
- Fornece avisos consistentes também na API de funções externas e memória (FFM)
- Emite avisos em preparação para futuras restrições de uso do JNI e da API FFM
- O aplicativo pode ativar a interface opcionalmente quando necessário
-
JEP 475: Late Barrier Expansion for G1
- Simplifica a implementação de barriers no coletor de lixo G1
- Ajusta o momento da expansão das barriers dos estágios iniciais para os estágios finais no compilador JIT C2
-
JEP 478: Key Derivation Function API (preview)
- Introduz a API Key Derivation Function (KDF) para derivação de chaves criptográficas
- Permite derivar chaves adicionais a partir de chaves secretas e outros dados
-
JEP 483: Ahead-of-Time Class Loading & Linking
- Permite que classes da aplicação fiquem disponíveis imediatamente na inicialização da HotSpot JVM
- Armazena em cache o estado carregado e vinculado após uma execução para acelerar inicializações posteriores
-
JEP 484: Class-File API
- Fornece uma API padrão para análise, geração e transformação de arquivos de classe Java
-
JEP 485: Stream Gatherers
- Adiciona suporte a operações intermediárias personalizadas na Stream API
- Permite transformações de dados difíceis de realizar com as operações intermediárias existentes
-
JEP 486: Permanently Disable the Security Manager
- O Security Manager já não era o principal mecanismo de segurança para código do lado do cliente
- Foi desativado após ser marcado para remoção no Java 17 (JEP 411)
- A API do Security Manager deverá ser removida por completo em uma versão futura
-
JEP 487: Scoped Values (quarta preview)
- Introduz Scoped Values para compartilhar dados imutáveis com threads filhas dentro de uma thread
- Pode reduzir custo de memória e tempo em comparação com variáveis locais de thread
- Espera-se melhora de desempenho quando usado com virtual threads e concorrência estruturada
-
JEP 488: Primitive Types in Patterns, instanceof, and switch (segunda preview)
- Suporte a tipos primitivos em pattern matching
- Permite usar todos os tipos primitivos em
instanceof e switch
-
JEP 489: Vector API (nono incubator)
- Introduz uma API para operações vetoriais
- Espera-se melhor desempenho que operações escalares ao compilar para instruções vetoriais
-
JEP 490: ZGC: Remove the Non-Generational Mode
- Remove o modo não geracional do ZGC e define o modo geracional como padrão
-
JEP 491: Synchronize Virtual Threads without Pinning
- Melhora o comportamento de virtual threads em blocos
synchronized para liberar a platform thread
- Evita que a virtual thread fique presa à platform thread, melhorando desempenho e escalabilidade
-
JEP 492: Flexible Constructor Bodies (terceira preview)
- Permite instruções antes de chamadas explícitas de construtor (
super(..), this(..))
- Possibilita inicializar campos antes que a instância esteja totalmente inicializada
-
JEP 494: Module Import Declarations (segunda preview)
- Adiciona declarações para importar de forma simples os pacotes exportados por um módulo
- Simplifica a reutilização de bibliotecas modularizadas
-
JEP 495: Simple Source Files and Instance Main Methods (quarta preview)
- Suporte a arquivos-fonte simples e métodos para facilitar a escrita por iniciantes
- Permite criar programas simples sem código complexo
-
JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
- Introduz o Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) resistente a computação quântica
- Reforça a segurança de chaves simétricas e prepara contra ataques de computação quântica
-
JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
- Introduz o Module-Lattice-Based Digital Signature Algorithm (ML-DSA) resistente a computação quântica
- Reforça a proteção contra adulteração de dados e a autenticação do signatário
- Prepara para futuros ataques de computação quântica
-
JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
- Emite avisos ao usar métodos de acesso à memória de
sun.misc.Unsafe
- Recomenda migração para a API VarHandle e a API FFM
-
JEP 499: Structured Concurrency (quarta preview)
- Introduz concorrência estruturada para tratar grupos de tarefas relacionadas como uma única unidade de trabalho
- Simplifica tratamento de erros e cancelamento, além de melhorar confiabilidade e visibilidade
[Resumo dos novos recursos do JDK 24]
-
Configurable New Session Tickets Count for TLSv1.3
-
Mechanism to Disable TLS Cipher Suites by Pattern Matching
- Permite desativar suítes de cifra TLS pela propriedade
jdk.tls.disabledAlgorithms no arquivo de configuração java.security
- Suporte a correspondência por padrão (com wildcard
_)
- Exemplo:
"TLS_RSA_*" desativa todas as suítes de cifra que começam com TLS_RSA
-
New Option to Extract a JAR File to a Specific Directory Using the jar Tool
-
New Reader.of(CharSequence) Method
- Adiciona o novo método factory estático
java.io.Reader.of(CharSequence)
- Permite leitura eficiente a partir de
String, StringBuilder etc.
-
New Method Process.waitFor(Duration)
- Adiciona o método
java.lang.Process#waitFor(Duration)
- Evita confusão com configuração de unidades no
waitFor() existente
-
Support for Unicode 16.0
- Adiciona suporte ao Unicode 16.0
- Total de 154.998 caracteres e 7 novos scripts adicionados
- Garay (África Ocidental)
- Gurung Khema, Kirat Rai, Ol Onal, Sunuwar (Índia e Nepal)
- Todhri (Albânia)
- Tulu-Tigalari (sudoeste da Índia)
-
New JAR Command Option to Not Overwrite Existing Files
-
New MXBean to Monitor and Manage Virtual Thread Scheduler
- Adiciona a interface
jdk.management.VirtualThreadSchedulerMXBean
- Permite monitorar o estado e o paralelismo do agendador de virtual threads
- Permite alterar dinamicamente o paralelismo alvo do agendador
-
New jcmd Commands Thread.vthread_scheduler and Thread.vthread_pollers
- Adiciona novos comandos à ferramenta
jcmd
Thread.vthread_scheduler: exibe o estado do agendador de threads
Thread.vthread_pollers: exibe o estado dos pollers de I/O
-
Support for Including Security Properties Files
- Permite incluir outros arquivos de propriedades no arquivo de configuração
java.security
- Usa
include <caminho do arquivo>
- A palavra-chave
include não pode ser usada como nome de propriedade
-
Document Standard Hash and MGF Algorithms for RSASSA-PSS Signature
- Documenta os algoritmos padrão de hash e função geradora de máscara disponíveis para assinaturas RSASSA-PSS
-
SunPKCS11 Provider Is Enhanced to Use CKM_AES_CTS Mechanism
- Adiciona suporte à transformação AES/CTS no provider SunPKCS11
- Adiciona a nova propriedade de configuração
cipherTextStealingVariant (CS1, CS2, CS3)
- No NSS, o valor padrão é CS1
-
New Summary Page for External Specifications
- Adiciona uma página de resumo para visualizar de uma só vez as especificações externas referenciadas pelo Java SE e pelas APIs do JDK
-
jpackage Supports WiX Toolset v4 and v5 on Windows
- O
jpackage passa a oferecer suporte ao WiX Toolset v4 e v5
- Seleciona automaticamente a versão de instalação mais recente
- Converte automaticamente fontes customizadas no formato WiX v3 para o formato v4
-
Add W3C DTDs and XSDs to the JDK Built-in Catalog
- Adiciona DTDs e XSDs do W3C ao catálogo XML embutido do JDK
- Permite carregamento local sem rede
- Itens adicionados:
- namespace xml
- XML Schema Part 1 & 2
- XHTML 1.0 & 1.1
- DTD da especificação XML do W3C
4 comentários
O Project Valhalla já está em desenvolvimento há muito tempo, então espero que traga bons frutos.
Pessoalmente, espero bastante que a estrutura plana das value classes reduza as referências por ponteiro e traga uma boa vantagem na velocidade de acesso à memória.
Parece que ele está recebendo muita influência (positiva) do Kotlin. Hoje em dia estou realmente muito satisfeito usando a linguagem Kotlin, mas também torço pelo Java, que pode ser considerado a origem.
Structured Concurrency e Scoped Value são coisas que eu espero bastante.
Comentários do Hacker News
O SecurityManager desapareceu silenciosamente. Um professor que dava uma disciplina optativa de Java no passado frequentemente destacava as vantagens do SecurityManager. Na época eu era bastante cético, e agora fico satisfeito em ver que esse ceticismo estava certo
Quero que a prévia de concorrência estruturada termine logo. Isso ajuda o Java a reduzir a última diferença em relação ao golang na facilidade de programação concorrente. O Go facilita canais e wait groups. A concorrência estruturada permite usar esses elementos básicos para escrever e entender tarefas de nível mais alto com mais facilidade
O fato de não haver mais pinning de virtual threads é uma grande vantagem. Agora dá para usar virtual threads praticamente sem limitações
É bom ver que Streams ainda continuam queridas. Na empresa fazemos muitas entrevistas no estilo fizzbuzz, e quem escolhe Java e usa streams geralmente passa. Isso mostra a ergonomia e a intuitividade da linguagem, além do poder da abstração. Os streams de Java são tão poderosos quanto cadeias de operações em estilo funcional do Ruby, mas com bom desempenho de verdade
Novos recursos: link do projeto OpenJDK 24
As versões para ARM32 e Risc-V poderão ser encontradas em breve aqui
O Raspberry 2 e o Vision Five 2 são hardwares muito voltados para o futuro, mas ignorados pela Oracle e pelo OpenJDK
Pergunta sobre a diferença de licença entre usar OpenJDK e as versões oficiais do Oracle JDK
Surpreende que o JEP 491 ainda não tenha sido mencionado. Ele garante que a palavra-chave "synchronized" não atrapalhe as virtual threads. É uma grande vantagem para rodar código existente em virtual threads
O avanço das versões do Java nos últimos anos foi interessante. Passei por Java 9, 10 e 11 LTS e ainda continuo usando Java 8. Há muito trabalho pela frente
Ao comparar as versões mais recentes de Java e Kotlin, o Java continua melhorando e incorporando recursos do Kotlin, mas o Kotlin também segue evoluindo por conta própria
O GraalVM também pode ser usado com Java 24. Há muitos bons recursos
O pinning em virtual threads finalmente acabou