Pular para o conteúdo principal

Java 17

  



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

Postagens mais visitadas deste blog

Certificação Java 11 - O que mudou

Certificação Java 11 - O que mudou A Oracle liberou recentemente uma atualização das suas certificações Java para atender a nova versão Java 11  LTS (Long Term Support) . Mas o que muda em relação a certificação Java 8? Preciso me atualizar? Por onde começo?  Neste post, vamos responder estas e outras questões sobre essa nova série de certificações. Caso você não tenha acompanhado a série sobre certificação, recomendo a leitura dos posts anteriores: https://www.guiadojava.com.br/2018/06/guia-da-certificacao-java-se-8.html Também temos um bate papo com os maiores especialistas de Java do mercado. Assista o replay aqui: https://events.genndi.com/replay/169105139238448348/23a5b3a7b0/0/83729443273C Nomenclatura e requisitos A partir de agora, você não receberá o certificado se fizer apenas a primeira prova, como era no Java 8 (1Z0-808 - Java SE 8 Programmer I). Você terá que fazer duas provas para obter o certificado " Oracle Certified Professional: Java SE 11 Dev

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

Java Records

  Java Records Imutável, Simples e limpa Esta funcionalidade da linguagem apareceu pela primeira vez na versão 14 como experimental e assim continuou até a versão 15 . Agora liberada de forma definitiva no Java 16 . O objetivo é ser possível ter classes que atuam como portadores transparentes de dados imutáveis. Os registros podem ser considerados tuplas nominais. Ou seja, após criado, um record não pode mais ser alterado. Records oferece uma uma sintaxe compacta para declarar classes que são portadores transparentes para dados imutáveis superficiais visando reduzir significamente o detalhamento dessas classes e irá melhorar a capacidade de leitura e manutenção do código. Vamos seguir um exemplo de uma classe chamada Pessoa . O primeiro exemplo vamos utilizar o modo tradicional. public class Pessoa { private String nome; private int idade; public Pessoa (String nome, int idade) { super (); this .nome = nome; this .idade = idade; } public String getNo