O que há de novo no Java 17?

A versão LTS (Long-Term-Support) da linguagem Java e da plataforma de tempo de execução Java 17 foi lançada em 14 de setembro de 2021. Vamos aprender o que há de novo no Java 17 e se você deve atualizar.

Muitos aplicativos usam versões mais antigas do Java, incluindo as versões LTS anteriores do Java: Java 11 e Java 8.

Por que as empresas devem atualizar para a versão mais atual do Java? A atualização para Java 17 requer esforço, principalmente para aproveitar ao máximo os novos recursos e funções dentro da JVM.

Muitas empresas usam imagens do Docker e do Docker para alternar para o Java 17 facilmente com o mínimo de esforço e tempo. Os desenvolvedores podem definir seus pipelines de integração/implantação contínua (CI/CD) e executar tudo em imagens do Docker. Isso não afetará outras equipes que usam versões Java mais antigas, pois elas podem utilizar imagens antigas do Docker.

Recursos do JAVA 17

Suporte macOS e AArch64

Um dos recursos JVM críticos adicionados a esta versão é o aprimoramento do suporte para macOS na arquitetura AArch64 usando JEP 391. Ele suportará a última série de processadores (M1) que a Apple lançou com seus computadores no ano passado.

Não é necessariamente um grande problema para os usuários dessas plataformas, já que alguns fornecedores lançaram versões do JDK que suportam essa arquitetura e até mesmo retornam o suporte do Java 8. No entanto, o selo de aprovação oficial é essencial para garantir a manutenção e suporte futuros de a plataforma. Em comparação, o suporte para a plataforma Linux/AArch64 foi adicionado ao Java 9 e Windows/AArch64 no Java 16.

Aulas Seladas

Classes Seladas é um recurso que foi introduzido no Java 17. O recurso Classes seladas terminou sua fase de teste e se tornou uma plataforma e linguagem oficial em Java 17. Ele permite que um desenvolvedor especifique os subtipos permitidos que um tipo pode ter e impedir que outros o estendam ou implementem de uma forma não pretendida.

As classes seladas também permitem que o compilador gere erros em tempo de compilação quando você tenta converter um tipo não selado em um subtipo não permitido. O Java 17 também traz um novo pipeline de renderização para aplicativos AWT/Swing executados no macOS usando a API Apple Metal em vez de OpenGL. Possui uma API aprimorada e recursos aprimorados para gerar números aleatórios.

  Os CDs que você gravou estão indo mal: aqui está o que você precisa fazer

Alterações, exclusões e limitações no Java 17

O Java 17 também traz diversas alterações, exclusões e novas limitações.

Encapsulamento de internos do JDK

Uma mudança é a conclusão do processo de encapsulamento do JDK Internals. A primeira vez que isso foi introduzido foi no Java 9 e forneceria avisos durante o tempo de execução quando um usuário tentasse usar reflexão ou algo semelhante para contornar as restrições usuais de uso de APIs internas. Argumentos de linha de comando também foram adicionados para regular esse comportamento.

A partir do Java 9, várias APIs foram criadas para oferecer uma maneira uniforme de executar as tarefas mais usadas; os usuários utilizariam essas APIs internamente. Com o Java 16, o padrão foi alterado de um aviso para desabilitar o acesso para lançar uma exceção. No entanto, ele usa o argumento de linha de comando para alterar o comportamento.

Com o Java 17, o argumento de linha de comando é eliminado e é possível desativar essa restrição. Isso significa que todo acesso não autorizado a essas APIs internas agora está protegido.

Semântica de ponto flutuante sempre estrita

Uma “remoção” adicional pode ser descrita como a reintrodução da semântica de ponto flutuante sempre estrito. O Java 1.2 introduziu modificações no padrão semântico de ponto flutuante em Java que permite que a JVM negocie com uma pequena quantidade de precisão em cálculos de ponto flutuante para melhorar o desempenho. Em classes e métodos onde a semântica estrita tinha que ser usada, uma palavra-chave strictfp foi adicionada. Desde então, vários tipos de conjuntos de instruções foram introduzidos nas CPUs, fazendo com que a semântica estrita de ponto flutuante fosse usada sem custos desnecessários. A necessidade de implementar uma semântica padrão ou estrita foi eliminada.

O Java 17 remove a semântica padrão anterior e todas as operações de ponto flutuante são executadas estritamente. O termo strictfpi ainda está presente. No entanto, não tem efeito e causa um aviso em tempo de compilação.

Compilação antecipada (AOT)

O Java 9 introduziu a compilação antecipada (AOT) como um recurso experimental que utiliza o compilador Graal, e um código JIT foi escrito usando Java. O Java 10 tornou o compilador Graal utilizável como um compilador JIT no OpenJDK, incorporando a interface JVMCI. Desde que foi lançado, tem sido uma grande melhoria. O compilador Graal viu enormes avanços e tem sua JVM sob o nome de GraalVM.

Ativação RMI

A ativação de RMI foi eliminada em PEC 407 após sua remoção do Java 8 e finalmente obsoleto e marcado como um requisito para remoção no Java 15. A Ativação de RMI forneceu um método para habilitar recursos sob demanda de objetos distribuídos usando RMI. No entanto, viu um uso mínimo e uma alternativa melhor está disponível no presente. O restante do RMI não é afetado pela eliminação da porção de Ativação.

  Por que você deve atualizar todo o seu software

Remoção da API do miniaplicativo

A API do Applet foi finalmente designada para remoção por PEC 398, removido inicialmente no Java 9. A API do Applet forneceu uma maneira de integrar os controles Java AWT/Swing em uma página da Web em um navegador. No entanto, nenhum navegador moderno pode suportar isso, o que significa que os Applets ficaram essencialmente inacessíveis na última década.

Gerente de segurança

A depreciação mais crucial é o gerenciador de segurança ( PEC 411). O Security Manager está em uso há algum tempo desde o Java 1.0. Ele foi projetado para restringir o que o Java poderia fazer localmente na máquina, como limitar o acesso a redes, arquivos e outros recursos de rede. Ele também tenta sandbox código que não é confiável bloqueando a reflexão e APIs específicas.

O fim do Security Manager começou no Java 12. Um argumento de linha de comando foi incluído para bloquear o uso do gerenciador de segurança no tempo de execução. A mudança feita no Java 17 significa que um aviso de tempo de execução será gerado na JVM ao tentar configurar um Security Manager, seja a partir da linha de comandos ou dinamicamente em tempo de execução.

Recursos de incubadora e visualização

Muitos se perguntaram se o Java 17 teria algum recurso de visualização e incubadora, considerando que o Java 17 foi promovido para ser uma versão com suporte de longo prazo. O Java 17 possui dois módulos incubadores e um recurso de visualização!

API de vetores

API de vetor ( PEC 414) está atualmente em sua segunda fase da incubadora. A API permite que os desenvolvedores definam a computação vetorial que o compilador JIT converterá na instrução vetorial apropriada suportada pela arquitetura de CPU na qual a JVM é executada (por exemplo, usando os conjuntos de instruções SSE ou AVX).

Antes, os desenvolvedores tinham que usar funções escalares ou construir bibliotecas nativas específicas para a plataforma. A implementação da API Vector em Java também fornece um mecanismo de fallback contínuo que era complicado nas versões anteriores.

A padronização da API Vector permite que as classes dentro do JDK a utilizem. Os métodos mismatch() do Java Arrays podem ser alterados para serem executados em Java, eliminando a necessidade de manter e gravar várias implementações específicas de plataformas na JVM.

Função externa e API de memória

Um recurso de incubadora adicional é chamado de API de memória e função estrangeira ( PEC 412). É uma evolução e fusão de dois outros módulos da incubadora do Java 16 que é a API Foreign Linker ( PEC 389) e API de memória externa ( PEC 393). Ambos fornecem acesso à memória e código nativos usando programação com tipagem estática escrita em Java.

  12 bibliotecas de gráficos financeiros rápidas e ricas em recursos para seu próximo aplicativo

Correspondência de padrão para switch

O recurso final da visualização de linguagem incluída no Java 17 é a inclusão de Correspondência de Padrões para Switch ( PEC 406). Esse recurso de linguagem expande as expressões e instruções do switch de acordo com o tipo, semelhante à sintaxe usada por meio do Pattern Matching (PEC 394), que se tornou padrão com o Java 16.

No passado, se você quisesse executar ações diferentes com base na natureza dinâmica de um objeto, seria necessário construir uma cadeia if-else usando uma instância de verificações como:

String type(Object o) {
  if (o instanceof List) {
    return "A List of things.";
  }
  else if (o instanceof Map) {
    return "A Map! It has keys and values.";
  }
  else if (o instanceof String) {
    return "This is a string.";
  }
  else {
    return "This is something else.";
  }
}

Ao combinar a expressão switch, bem como o novo recurso de correspondência de padrões para switches, o processo pode ser reduzido a algo semelhante a:

String type(Object o) {
  return switch (o) {
    case List l -> "A List of things.";
    case Map m -> "A Map! It has keys and values.";
    case String s -> "This is a string.";
    default -> "This is something else.";
  };
}

Como você deve ter notado, há a declaração de uma variável no processo de verificação. Como as outras variáveis ​​em Pattern, a correspondência de instância indica que este objeto foi verificado e convertido e está disponível a partir da variável dentro de sua área atual.

A função de visualização é outro passo para a correspondência de padrões. O próximo passo é incluir a capacidade de desconstruir arrays e registros.

Você deve atualizar para o Java 17?

Sim, você deve atualizar constantemente para a versão mais recente, mas não logo no primeiro dia. O software e as bibliotecas que você está usando podem não ter sido atualizados para incluir compatibilidade com o Java 17, portanto, talvez seja necessário aguardar algum tempo até que isso seja feito.

Se você está preso a uma versão LTS do Java, como Java 8 ou Java 11, existem inúmeras opções dentro da linguagem e dentro da própria JVM que requerem uma atualização até o Java 17. Por ser uma versão de manutenção de longo prazo, há uma grande chance de que seu ambiente de produção também seja atualizado para o Java 17.

Se você está iniciando um projeto totalmente novo ou está no processo de preparar seu projeto para o Java 17, mudar para o Java 17 o quanto antes é provavelmente a escolha mais eficiente, pois reduz os custos de mudança. Isso também permite que os desenvolvedores que trabalham no projeto utilizem todos os recursos mais recentes e o lado operacional.

Você pode aproveitar as muitas melhorias que ocorreram nos últimos anos, como suporte aprimorado para contêineres em execução em Java, bem como novas implementações de coletor de lixo de baixa latência.