Versão Java SE 17

Após seis meses de desenvolvimento, a Oracle lançou o Java SE 17 (Java Platform, Standard Edition 17), que usa o projeto OpenJDK de código aberto como implementação de referência. Com exceção da remoção de alguns recursos obsoletos, o Java SE 17 mantém compatibilidade retroativa com versões anteriores da plataforma Java - a maioria dos projetos Java escritos anteriormente funcionarão sem alterações quando executados na nova versão. Compilações prontas para instalação do Java SE 17 (JDK, JRE e Server JRE) são preparadas para Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). Desenvolvida pelo projeto OpenJDK, a implementação de referência Java 17 é totalmente open source sob a licença GPLv2, com exceções GNU ClassPath permitindo vinculação dinâmica com produtos comerciais.

O Java SE 17 é classificado como uma versão Long Term Support (LTS), que continuará recebendo atualizações até 2029. As atualizações para a versão anterior do marco do Java 16 foram descontinuadas. A ramificação LTS anterior do Java 11 terá suporte até 2026. O próximo lançamento LTS está agendado para setembro de 2024. Lembramos que a partir do lançamento do Java 10, o projeto passou para um novo processo de desenvolvimento, implicando em um ciclo mais curto para a formação de novos lançamentos. A nova funcionalidade agora é desenvolvida em um branch master constantemente atualizado, que inclui alterações prontas e a partir do qual os branchs são ramificados a cada seis meses para estabilizar novos lançamentos.

Os novos recursos do Java 17 incluem:

• É proposta uma implementação experimental de correspondência de padrões em expressões “switch”, que permite usar não valores exatos em rótulos “case”, mas modelos flexíveis cobrindo uma série de valores ao mesmo tempo, para os quais anteriormente era necessário usar complicados cadeias de expressões “if...else”. Além disso, “switch” tem a capacidade de lidar com valores NULL. Objeto o = 123L; String formatada = switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Duplo d -> String.format("duplo %f", d); case String s -> String.format("String %s", s); padrão -> o.toString(); };
• Suporte estabilizado para classes e interfaces seladas, que não podem ser usadas por outras classes e interfaces para herdar, estender ou substituir a implementação. As classes seladas também fornecem uma maneira mais declarativa de restringir o uso de uma superclasse do que os modificadores de acesso, com base na lista explícita das subclasses permitidas para extensão. pacote com.example.geometry; classe pública selada Shape permite com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}
• É proposta uma segunda prévia da API Vector, que fornece funções para cálculos vetoriais que são executados usando instruções vetoriais em processadores x86_64 e AArch64 e permitem que operações sejam aplicadas simultaneamente a múltiplos valores (SIMD). Ao contrário dos recursos fornecidos no compilador HotSpot JIT para autovetorização de operações escalares, a nova API torna possível controlar explicitamente a vetorização para processamento paralelo de dados.
• Adicionada uma visualização da API Foreign Function & Memory, que permite que os aplicativos interajam com código e dados fora do tempo de execução Java. A nova API permite chamar com eficiência funções não JVM e acessar memória não gerenciada por JVM. Por exemplo, você pode chamar funções de bibliotecas compartilhadas externas e acessar dados de processo sem usar JNI.
• O mecanismo de renderização do macOS que alimenta a API Java 2D, que por sua vez alimenta a API Swing, foi adaptado para usar a API gráfica Metal. A plataforma macOS continua a usar OpenGL por padrão, e a ativação do suporte Metal requer a configuração "-Dsun.java2d.metal=true" e pelo menos a execução do macOS 10.14.x.
• Adicionada uma porta para a plataforma macOS/AArch64 (computadores Apple baseados nos novos chips Apple M1). Uma característica especial da porta é o suporte ao mecanismo de proteção de memória W^X (Write XOR Execute), no qual as páginas da memória não podem ser acessadas simultaneamente para escrita e execução. (o código pode ser executado somente após a gravação ser desabilitada, e a gravação em uma página de memória só é possível após a execução ser desabilitada).
• Revertido para usar apenas a semântica strictfp para expressões de ponto flutuante. O suporte à semântica “padrão”, disponível desde o lançamento do Java 1.2, foi descontinuado, incluindo simplificações para trabalhar em sistemas com coprocessadores matemáticos x87 muito antigos (após o advento das instruções SSE2, a necessidade de semântica adicional desapareceu).
• Novos tipos de interfaces para geradores de números pseudoaleatórios foram implementados e algoritmos adicionais foram implementados para melhor geração de números aleatórios. Os aplicativos têm a oportunidade de escolher um algoritmo para gerar números pseudoaleatórios. Suporte aprimorado para geração de fluxos de objetos aleatórios.
• Encapsulamento estrito imposto de todos os componentes internos do JDK, com exceção de APIs críticas, como sun.misc.Unsafe. O encapsulamento estrito bloqueia tentativas do código de acessar classes, métodos e campos internos. Anteriormente, o modo de encapsulamento estrito podia ser desabilitado usando a opção "--illegal-access=permit", mas agora está obsoleto. Os aplicativos que exigem acesso a classes, métodos e campos internos devem defini-los explicitamente usando a opção --add-opens ou o atributo Add-Opens no arquivo de manifesto.
• Os aplicativos têm a capacidade de definir filtros de desserialização de dados, que podem ser sensíveis ao contexto e selecionados dinamicamente com base em operações específicas de desserialização. Os filtros especificados são aplicáveis ​​a toda a máquina virtual (em toda a JVM), ou seja, abrangem não apenas o aplicativo em si, mas também as bibliotecas de terceiros usadas no aplicativo.
• Swing adicionou o método javax.swing.filechooser.FileSystemView.getSystemIcon para carregar ícones grandes para melhorar a IU em telas de alto DPI.
• A API java.net.DatagramSocket fornece suporte para conexão com grupos Multicast sem a necessidade de uma API java.net.MulticastSocket separada.
• O utilitário IGV (Ideal Graph Visualizer) foi aprimorado, fornecendo visualização interativa da representação de código intermediário no compilador HotSpot VM C2 JIT.
• No JavaDoc, por analogia com o compilador javac, quando um erro é gerado, o número da linha problemática no arquivo fonte e a localização do erro são agora indicados.
• Adicionada a propriedade native.encoding, refletindo o nome da codificação de caracteres do sistema (UTF-8, koi8-r, cp1251, etc.).
• A interface java.time.InstantSource foi adicionada, permitindo a manipulação do tempo sem referência a um fuso horário.
• Adicionada API java.util.HexFormat para conversão para representação hexadecimal e vice-versa.
• Um modo blackhole foi adicionado ao compilador, que desativa operações de eliminação de código morto, que podem ser usadas ao realizar testes de desempenho.
• Adicionada opção “-Xlog:async” ao Runtime para registrar logs em modo assíncrono.
• Ao estabelecer conexões seguras, o TLS 1.3 é habilitado por padrão (anteriormente era usado o TLS 1.2).
• A API Applet obsoleta anteriormente declarada (java.applet.Applet*, javax.swing.JApplet), que era usada para executar aplicativos Java no navegador, foi movida para a categoria de remoção prevista (relevância perdida após o fim do suporte para o plugin Java para navegadores).
• O Security Manager, que há muito perdeu sua relevância e acabou não sendo reclamado após o fim do suporte ao plugin do navegador, foi movido para a categoria daqueles programados para remoção.
• Foi removido o mecanismo de ativação RMI, que está desatualizado, relegado à categoria de opção no Java 8 e quase nunca é usado na prática moderna.
• Um compilador experimental que suporta JIT (just-in-time) para compilação dinâmica de código Java para HotSpot JVM, bem como o modo de compilação antecipatória (AOT, ahead-of-time) de classes em código de máquina antes de iniciar a máquina virtual , foi removido do SDK. O compilador foi escrito em Java e baseado no trabalho do projeto Graal. Nota-se que a manutenção do compilador exige muita mão de obra, o que não se justifica quando não há demanda dos desenvolvedores.

Fonte: opennet.ru