Java 17
A tão esperada versão LTS depois do Java 11 acabou de ser liberada. E sabe porque não houve tanto barulho na comunidade? Porque esta versão já vem sendo experimentada desde a própria versão 11.
Nova Cadência
Este é o oitavo lançamento de recurso entregue no prazo ao longo da cadência de lançamento de seis meses. Esse nível de previsibilidade permite que os desenvolvedores gerenciem facilmente sua adoção de inovação, graças a um fluxo constante de mudanças esperadas.
Abaixo uma tabela com as releases e as funcionalidades liberadas em cada uma delas. Graças a esta cadência, não precisamos esperar por anos para experimentar e usar uma nova funcionalidade.
Java 17 é a segunda com suporte de longo prazo (LTS) sob a cadência de lançamento anunciada em 2018. A Oracle anunciou planos para encurtar o tempo entre lançamentos de LTS futuros, de 3 anos para 2 anos, então você deve esperar que o próximo LTS seja Java 21 em setembro de 2023.
Opções de download
Como a Oracle é a principal mantenedora do projeto OpenJDK é normal que nos primeiros dias após o lançamento somente seja possível fazer o download através do site do próprio projeto ou pelo site da Oracle
UPDATE
Link para download do projeto AdoptOpenJDK
https://adoptium.net/releases.html?variant=openjdk17
1. Listagem de Features
JEP 409: Sealed Classes
Classes seladas permitem que designers de API especifiquem quais classes ou interfaces podem estender ou implementar uma determinada classe. Ter uma lista exaustiva de casos a serem considerados ao modelar um problema pode simplificar o desenvolvimento. O JEP 409 foi desenvolvido no OpenJDK Project Amber, que visa melhorar continuamente a produtividade do desenvolvedor por meio da evolução da linguagem de programação Java.
public sealed class Animal permits Dog, Cat {
}
O código acima indica que somente as classes Dog e Cat podem extender a classe Animal. Qualquer tentativa de extender animal em outra classe, causará um erro de compilação.
2. Atualizações e melhorias nas bibliotecas principais
JEP 306: Restore Always-Strict Floating-Point Semantics
A linguagem de programação Java e a máquina virtual Java originalmente tinham apenas uma semântica de ponto flutuante estrita. A partir do JDK 1.2, pequenas variações nessas semânticas estritas foram permitidas por padrão para acomodar as limitações das arquiteturas de hardware atuais. Essas variações não são mais úteis ou necessárias e foram removidas pelo JEP 306.
JEP 356: Enhanced Pseudo-Random Number Generator
As atualizações de java.util.random melhoram a interoperabilidade de diferentes PRNGs (geradores de números pseudo-aleatórios) e tornam mais fácil solicitar um algoritmo baseado em requisitos, em vez de codificar uma implementação específica. As alterações incluem novos tipos de interface e implementações para geradores de números pseudo-aleatórios (PRNGs), incluindo PRNGs puláveis e uma classe adicional de algoritmos PRNG separáveis (LXM) e uma nova classe RandomGeneratorFactory.
JEP 382: New macOS Rendering Pipeline
Este novo pipeline reduz a dependência do JDK na API Apple OpenGL obsoleta, implementando um pipeline de renderização Java 2D para macOS usando a nova API Apple Metal.
JEP 415: Context-Specific Deserialization Filters
O Filtro de Dados de Serialização de Entrada, adicionado com JDK 9 (JEP 290), foi aprimorado permitindo que os aplicativos configurem filtros de desserialização específicos do contexto e selecionados dinamicamente por meio de uma fábrica de filtros em toda a JVM que é chamada para selecionar um filtro para cada operação de desserialização individual. Isso torna possível tirar proveito dos filtros de desserialização sem exigir que cada criador de stream atualize seu código ou tornar o filtro muito restritivo ou permissivo.
3. New Platform Support
JEP 391: macOS AArch 64 Port
Oferece uma versão do JDK para macOS que roda nativamente nos sistemas mais recentes da Apple baseados em Arm 64.
4. Previews and Incubators
JEP 406: Pattern Matching for switch (Preview)
Aprimora a linguagem de programação Java, permitindo que "pattern matching" seja testada em uma instrução switch ou expressão switch. O uso de "pattern matching" em consultas complexas orientadas a dados do switch pode ser expresso de forma concisa e segura. Esta JEP está sendo desenvolvida no Projeto Amber.
JEP 412: Foreign Function and Memory API (Incubator)
Aprimora as APIs introduzidas com JDK 14 e JDK 15 por meio das quais programas Java podem interoperar com código e dados fora do Java runtime. Invocando com eficiência funções externas (ou seja, código fora da JVM) e acessando com segurança a memória externa (ou seja, 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 de JNI. O JEP 412 foi desenvolvido no Projecto Panama, que visa simplificar a interação entre o código Java e APIs externas (não Java).
JEP 414: Vector API (Second Incubator)
Aprimora APIs que permitem expressar cálculos de vetor de uma maneira que compilará de forma confiável em tempo de execução para obter instruções de vetor ideais em arquiteturas de CPU suportadas. As operações de vetor podem oferecer desempenho superior a cálculos escalares equivalentes e são bastante comuns em áreas como Aprendizado de Máquina, Inteligência Artificial e Criptografia.
5. Future Proofing Java Programs
JEP 403: Strongly Encapsulate JDK Internals
Não será mais possível relaxar o encapsulamento forte de elementos internos por meio de uma única opção de linha de comando, como era possível no JDK 9 até o JDK 16. Essa alteração oculta por padrão, exceto algumas APIs internas críticas, como sun.misc.Unsafe. Ainda será possível acessar APIs internas existentes, mas isso agora exigirá enumerar, como parâmetros de linha de comando ou atributos de manifesto de arquivo JAR, cada pacote no qual o encapsulamento deve ser relaxado. A mudança levará a aplicativos mais seguros e menos dependências de implementações internas não padrão.
6. Deprecations and Removals
JEP 411: Deprecate the Security Manager for Removal
O Security Manager ainda é do Java 1.0. Não foi o principal meio de proteger o código Java do lado do cliente por muitos anos e raramente foi usado para proteger o código do lado do servidor.
JEP 398: Deprecate the Applet API for Removal
A API Applet tornou-se essencialmente irrelevante, uma vez que todos os fornecedores de navegadores web removeram o suporte para plug-ins de navegador Java ou anunciaram planos para fazê-lo. A API Applet foi descontinuada anteriormente (embora não para remoção) no Java 9 (JEP 289) em setembro de 2017.
JEP 407: Remove RMI Activation
O mecanismo de ativação do Remote Method Invocation (RMI) foi removido. Esta mudança não afeta o resto do RMI. O mecanismo de ativação RMI foi descontinuado para remoção no JDK 15 em setembro de 2020.
7. For OpenJDK Contributors
JEP 410: Remove the Experimental AOT and JIT Compiler
O compilador experimental baseado em Java (AOT) e just-in-time (JIT) teve pouco uso desde sua introdução no JDK 9, surgiram alternativas mais amplamente suportadas e o esforço necessário para mantê-las é significativo. Como componentes opcionais, eles já foram removidos do JDK 16. Este JEP remove o código-fonte do projeto OpenJDK.
Artigo original (em inglês)
https://www.linkedin.com/pulse/arrival-java-17-sharat-chander/
Comentários
Postar um comentário