Todo mês de setembro, com regularidade metronômica, temos uma nova versão da plataforma Java. Um pequeno detalhe sobre o tempo é que o primeiro release candidate do JDK 27 foi adiado por duas semanas devido ao lançamento da primeira Atualização Crítica de Patch de Segurança (CPSU) para o JDK. A necessidade de um PCUS é uma implicação direta dos modelos de IA, como o de Claude Mythos da Anthropic, que se tornam muito melhores na identificação de vulnerabilidades e no desenvolvimento de explorações. Se você ainda não está reavaliando sua estratégia de patch para o JDK, você definitivamente deveria estar.
Como de costume, os novos recursos em cada versão do Java são impulsionados principalmente por um conjunto de JDK Enhancement Proposals (JEPs). No JDK 27, temos nove JEPs, e cinco deles são recursos que continuam a ser revisados sob o conceito de recurso de visualização e módulos incubadores.
Vamos começar com eles, já que as alterações são intencionalmente pequenas.
Recursos de visualização e incubadora no JDK 27
JEP 537 traz de volta a API vetorial para uma décima segunda incubadora recorde. Isso não ocorre porque a API tenha problemas significativos; é porque é um componente do Projeto Valhalla maior. Os autores da API não querem finalizá-la até que Valhalla seja entregue (mais sobre Valhalla posteriormente). Como tal, não há alterações na versão do JDK 26.
A simultaneidade estruturada retorna para uma sétima prévia sólida no JEP 533. Isso faz parte do OpenJDK Project Loom maior, um conjunto de recursos para melhorar a escalabilidade e a confiabilidade de aplicativos multithread. Apenas pequenas alterações nesta versão, principalmente no Joiner interface.
Constantes preguiçosas (JEP 531) retornam para uma terceira visualização. A ideia por trás desse recurso é a inicialização adiada e a confiança da JVM. Constantes preguiçosas são objetos que transportam dados, mas são tratadas como constantes verdadeiras pela JVM. Isso permite as mesmas otimizações de desempenho que a declaração de um campo final. Comparado com final campos, no entanto, as constantes lentas oferecem maior flexibilidade para os desenvolvedores quando são inicializadas. Existem apenas três pequenas alterações na API nesta versão.
Uma característica de particular interesse para mim é o JEP 532: tipos primitivos em padrões, instanceofe switch. Tenho ministrado uma sessão de “quebra-cabeças Java” em conferências e JUGs, o que levou a alguns pontos de discussão interessantes sobre como usar esse recurso. O JDK 26 reforçou algumas das regras sobre a dominância de padrões em switches, mas é entregue sem alterações no JDK 27.
O último recurso de visualização no JDK 27 é a codificação JEP 538, PEM (Privacy-Enhanced Mail) de objetos criptográficos, agora em sua terceira visualização. Esta API codifica e decodifica chaves criptográficas, certificados e listas de certificados revogados entre objetos e o formato de transporte PEM amplamente utilizado. Isso inclui uma série de pequenas alterações na API. Um que me chamou a atenção foi a mudança na classe PEM primária de um objeto normal para um registro. A razão para isso é a inclusão de novos construtores que aceitam conteúdo codificado em Base64 em matrizes de bytes.
Recursos finais no JDK 27
Vamos passar para os recursos restantes, todos finais.
JEP 534 agora ativa cabeçalhos de objetos compactos por padrão. Embora no JDK 25 os cabeçalhos de objetos compactos tenham sido tornados finais, eles exigiam um sinalizador de linha de comando explícito para habilitá-los em tempo de execução. Como uma mudança fundamental na JVM, eles agora provaram ser estáveis o suficiente para serem a configuração padrão. O benefício que eles trazem é um melhor desempenho através da redução do uso de heap (o JEP cita uma redução de 22% no espaço de heap e uma redução de 8% na utilização da CPU para o benchmark SPECjbb2015).
Outra mudança interessante é a JEP 523, que torna o coletor de lixo (GC) G1 o padrão em todas as situações. Desde o JDK 9, G1 tem sido o padrão para aplicativos do lado do servidor, mas o coletor serial permaneceu como padrão em ambientes com recursos limitados (aqueles com uma única CPU ou menos de 1.792 MB de memória física). Mudanças mais recentes no G1 permitem que ele funcione tão bem quanto o coletor serial em todos os ambientes. Suspeito que, com base nessa mudança, em breve veremos o coletor serial obsoleto e removido do OpenJDK.
Um recurso de som impressionante é o JEP 527, troca de chave híbrida pós-quântica para TLS 1.3. A criptografia pós-quântica (PQC) refere-se a algoritmos de criptografia e assinatura digital projetados para permanecer seguros contra ataques futuros de computadores quânticos. Os padrões criptográficos atuais, como RSA e ECC (Criptografia de Curva Elíptica), baseiam-se em problemas matemáticos, como fatoração de grandes números, que levam milhares de anos para os computadores padrão serem resolvidos. Computadores quânticos executando o algoritmo de Shor podem resolver esses problemas em horas ou minutos. Embora os computadores quânticos capazes de fazer isso não estejam disponíveis no momento, os cibercriminosos já estão coletando dados criptografados, presumindo que serão capazes de descriptografá-los com computadores quânticos no futuro. Este JEP integra algoritmos resistentes a quantum na camada padrão de segurança de rede e web do Java (TLS 1.3).
Por fim, temos a redação de dados em processo do JEP 536, JFR (Java Flight Recorder). Java Flight Recorder é uma estrutura de diagnóstico de baixa sobrecarga integrada à JVM. Ele grava informações de tempo de execução e de aplicativo como eventos com registro de data e hora em um arquivo de gravação. As gravações JFR normalmente incluem eventos que capturam argumentos de linha de comando, valores de variáveis de ambiente e propriedades do sistema, para que você possa ver como o processo foi iniciado e configurado. Esses eventos podem conter dados confidenciais, como segredos em argumentos de linha de comando, tokens de acesso em variáveis de ambiente e senhas em propriedades do sistema. O JFR irá agora redigir esses dados antes de saírem do processo, para que informações confidenciais não vazem. Quais informações são editadas podem ser controladas por meio de argumentos de linha de comando específicos.
Grandes mudanças chegando no JDK 28
Então, por que o título deste post é “O silêncio antes da tempestade”?
Olhando para os JEPs no JDK 27, é bastante silencioso em relação aos novos recursos, principalmente alterações incrementais nos recursos de visualização e algumas pequenas adições.
O que nos leva ao próximo lançamento, JDK 28. Embora o JDK 27 tenha acabado de ser lançado, já temos uma imagem de alguns dos JEPs que serão incluídos no JDK 28. No momento em que este artigo foi escrito, havia seis JEPs como alvo. Dois desses PEC introduzem mudanças que já existem há muito tempo e são fonte de muita discussão.
Primeiro, finalmente obteremos uma API JSON em Java, algo que está no escopo desde a introdução do JEP 128, em 2018. Este analisador é excepcionalmente rigoroso e não oferece nenhum modo tolerante (ao contrário de outras APIs de terceiros, como Jackson e Gson). Teremos que esperar e ver qual é o feedback da comunidade sobre isso.
Em segundo lugar, existe o JEP 541, que descontinua a porta macOS/x64. Com a mudança da Apple para chips de classe M baseados em Arm, a porta Intel para Macs será descontinuada.
Então chegamos à grande novidade do JDK 28: as primeiras partes reais do Projeto Valhalla. Existem dois JEPs para isso: JEP 401, que são objetos de valor, e JEP 539 (observe a diferença nos números), que é a inicialização estrita de campos na JVM.
Vou esperar até que o JDK 28 esteja pronto para lançamento antes de falar sobre isso em detalhes, mas é um momento emocionante para Java, com algumas grandes mudanças em andamento. Fique atento!
–
Fórum de Nova Tecnologia fornece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Enviar tudo consultas para [email protected].
