JDK 18: Os novos recursos do Java 18

JDK 18: Os novos recursos do Java 18

Com o lançamento em março, o Java 18 incuba uma API vetorial, disponibiliza o “pattern matching for switch statements” como preview feature, adota UTF-8 como o conjunto de caracteres padrão e inclui um servidor web simples.

O Java Development Kit (JDK) 18 está programado para ser lançado em 22 de março de 2022. A nova versão do Java padrão terá nove novos recursos, com o conjunto de recursos congelado em 9 de dezembro.

O JDK 18 passou para um estágio de release candidate, após duas fases de rampdown realizadas entre dezembro e fevereiro. Um segundo release candidate está previsto para 24 de fevereiro. As atualizações do Java padrão são lançadas a cada seis meses, com a versão mais recente, JDK 17, chegando em setembro de 2021.

A página OpenJDK lista os seguintes recursos como direcionados oficialmente ao JDK 18: uma interface de provedor de serviços, um servidor web simples, uma terceira incubação da API vetorial, trechos de código, uma reimplementação do core reflexão, um conjunto de caracteres UTF-8, uma segunda versão preview de uma função estrangeira e API de memória, uma segunda preview de correspondência de padrões para instruções switch (pattern matching for switch statements) e a descontinuação do finalization, que foi a última adição.

Enquanto o JDK 17 foi uma versão de suporte de longo prazo (LTS) que recebeu pelo menos oito anos de suporte da Oracle, o JDK 18 será uma versão de recurso de curto prazo com suporte por seis meses. As compilações de acesso antecipado do JDK 18 podem ser encontradas para Linux, Windows e MacOS em java.net.

As especificidades das propostas do JDK 18 incluem: 1 - Deprecate finalization for removal para remoção em uma versão futura. O Finalizer tem falhas que causam problemas significativos do mundo real em segurança, desempenho, confiabilidade e capacidade de manutenção. Ele também tem um modelo de programação difícil. A finalização está habilitada por padrão por enquanto, mas pode ser desabilitada para facilitar os testes iniciais. Ele será desabilitado por padrão em uma versão de recurso e removido completamente em uma versão posterior. A proposta exige uma opção de linha de comando para desativar a finalização e a descontinuação de todos os finalizadores e métodos de finalização na API Java padrão. Os objetivos da proposta incluem ajudar os desenvolvedores a entender os perigos da finalização, preparar os desenvolvedores para sua eventual remoção e fornecer ferramentas simples para ajudar a detectar a dependência da finalização. Introduzida no Java 1.0, a finalização visava ajudar a evitar vazamentos de recursos. Uma classe pode declarar um finalizador — o método protected void finalize() — cujo corpo libera qualquer recurso subjacente. O coletor de lixo agendará o finalizador de um objeto inacessível para ser chamado antes de recuperar a memória do objeto; por sua vez, o método finalize pode executar ações como chamar o fechamento do objeto. Isso parece ser uma rede de segurança eficaz para evitar vazamentos de recursos, mas existem falhas, incluindo latência imprevisível, com um longo tempo decorrido entre quando um objeto se torna inacessível e quando seu finalizador é chamado; comportamento irrestrito, com código finalizador capaz de realizar qualquer ação, incluindo ressuscitar um objeto e torná-lo acessível novamente; o finalizador está sempre habilitado, sem mecanismo de registro explícito; e os finalizadores podem ser executados em threads não especificados em uma ordem arbitrária. Dados os problemas com a finalização, os desenvolvedores são aconselhados a usar técnicas alternativas para evitar vazamentos de recursos, ou seja, declarações try-with-resources e limpadores. (Consulte a Proposta de Aprimoramento do JDK 421 para obter detalhes.)

2 - Para o Internet-address resolution SPI, a proposta é definir um SPI para resolução de endereços de host e nome para que Inet.Address possa fazer uso de resolvedores diferentes do resolvedor interno da plataforma. As motivações para este esforço incluem uma melhor habilitação do Project Loom, para concorrência e novos modelos de programação em Java, juntamente com a integração de novos protocolos de rede, customização e habilitação de testes. A proposta não envolve o desenvolvimento de um resolvedor alternativo para o JDK.

3 - O segundo preview do (pattern matching for switch), na qual a linguagem Java seria aprimorada com correspondência de padrões para expressões e instruções switch, juntamente com extensões para a linguagem de padrões. Isso foi visualizado no JDK 17. Estendendo a correspondência de padrões para switch que permite que uma expressão seja testada em vários padrões, cada um com uma ação específica, de modo que consultas complexas orientadas a dados possam ser expressas de forma concisa e segura.

4 - A reimplementação do core de reflexão com identificadores de método reimplementaria lang.reflect.Method, Constructor e Field sobre os identificadores de método java.lang.invoke. Ter alças de método servindo como mecanismo subjacente para reflexão reduzirá os custos de manutenção e desenvolvimento das APIs java.lang.reflect e java.lang.invoke.

5 - Com a proposta de servidor web simples, uma ferramenta de linha de comando seria fornecida para iniciar um servidor web mínimo que serve apenas arquivos estáticos. Nenhuma funcionalidade semelhante a CGI ou servlet está disponível. A ferramenta será útil para prototipagem, codificação ad-hoc e testes, particularmente em contextos educacionais. Os objetivos do plano incluem oferecer um servidor de arquivos HTTP estático pronto para uso com configuração fácil e funcionalidade mínima, reduzindo a energia de ativação do desenvolvedor e tornando o JDK mais acessível e fornecendo uma implementação padrão por meio da linha de comando junto com uma pequena API para criação e personalização programática. Fornecer um servidor rico em recursos ou de nível comercial não é um objetivo da proposta.

6 - Uma segunda preview de uma API de função e memória externa (foreign function and memory API), na qual uma API é introduzida por meio da qual programas Java podem interoperar com código e dados fora do tempo de execução Java. Ao invocar funções externas – código fora da JVM – e ao acessar com segurança a memória externa – memória não gerenciada pela JVM – a API permite que programas Java chamem bibliotecas nativas e processem dados nativos sem a fragilidade e o perigo da JNI (Java Native Interface). A intenção é substituir o JNI por um modelo de desenvolvimento Java puro e superior. Essa API foi incubada no JDK 17. Para o JDK 18, refinamentos seriam incorporados, com base no feedback, como suporte para mais operadoras como Boolean e MemoryAddress em handles de var de acesso à memória e uma nova API para copiar arrays Java de e para a memória segmentos.

7 - A API vetorial (The vector API) seria incubada pela terceira vez no JDK 18, tendo sido incubada anteriormente no JDK 16 e JDK 17. Esta proposta expressaria computações vetoriais que compilam em tempo de execução instruções vetoriais ideais em arquiteturas de CPU suportadas, alcançando desempenho superior ao equivalente cálculos escalares. As operações vetoriais expressam um grau de paralelização, permitindo que mais trabalho seja feito em um único ciclo de CPU, produzindo melhorias significativas de desempenho. A API de vetor independente de plataforma visa fornecer uma maneira de escrever algoritmos complexos em Java, usando o auto vetorizador HotSpot existente, mas com um modelo de usuário que torna a vetorização mais previsível. O JDK 18 também adicionaria suporte para a plataforma ARM Scalar Vector Extension e melhoraria o desempenho de operações vetoriais que aceitam máscaras em arquiteturas que suportam mascaramento em hardware.

8 - Specifying UTF-8 as the default charset of the standard Java APIs. UTF-8 é uma codificação de caracteres de largura variável para comunicação eletrônica e é considerado o conjunto de caracteres padrão da web. Charset é a codificação de caracteres capaz de codificar todos os caracteres na web. Por meio dessa alteração, as APIs que dependem do conjunto de caracteres padrão se comportaram de forma consistente em todas as implementações, sistemas operacionais, localidades e configurações. A proposta não se destina a definir novas APIs padrão Java ou específicas de JDK. Os proponentes da proposta esperam que os aplicativos em muitos ambientes não vejam nenhum impacto da escolha do Java pelo UTF-8, já que o MacOS, muitas distribuições Linux e muitos aplicativos de servidor já suportam UTF-8. No entanto, há risco em outros ambientes, sendo o mais óbvio que os aplicativos que dependem do conjunto de caracteres padrão se comportem incorretamente ao processar dados produzidos quando o conjunto de caracteres padrão não foi especificado. A corrupção de dados pode ocorrer silenciosamente. Espera-se que o principal impacto recaia sobre os usuários de sistemas Windows em localidades asiáticas e possivelmente em alguns ambientes de servidor na Ásia e em outras localidades.

9 - Code snippets in Java API documentation, envolvendo a introdução de uma tag @snippet para o Doclet padrão do JavaDoc, para simplificar a inclusão de código-fonte de exemplo na documentação da API. Entre os objetivos do plano está facilitar a validação de fragmentos de código-fonte, fornecendo acesso à API a esses fragmentos. Embora a correção seja de responsabilidade do autor, o suporte aprimorado em JavaDoc e ferramentas relacionadas pode torná-lo mais fácil de alcançar. Outros objetivos incluem habilitar estilos modernos, como realce de sintaxe, bem como a vinculação automática de nomes a declarações e habilitar melhor suporte de IDE para criar e editar trechos. A proposta observa que os autores da documentação da API geralmente incluem fragmentos de código-fonte nos comentários da documentação.
Referências

Artigo original em inglês.