Java JDK 11: saiba quais as novidades

Java 11

O suporte ao CORBA, Java EE e JavaFX serão removidos, mas em contrapartida 15 novos recursos serão lançados nesta versão prevista para Setembro

Java Developmemnt Kit (JDK) 11 está para ser lançado. Testamos o release candidate liberado em Agosto de 2018. A versão de produção está prevista para lançamento no próximo dia 25. A seguir vamos falar um pouco sobre os novos recursos.

Mas antes de falar sobre as novidades, vale dizer que nesta versão foram removidos os módulos CORBA e Java EE (recentemente renomeados como Jakarta EE), bem como a remoção do JavaFX.

Previsto para ser uma versão de longo prazo, diferente do JDK 10, o JDK 11 será uma implementação de referência da Plataforma Java, Standard Edition (Java SE) 11. Segundo a Oracle, O JDK 11 receberá suporte a nível avançado até 2023 e suporte estendido, com patches e alertas de segurança, até 2026. Novos lançamentos LTS (Long Term Support) são definidos a cada três anos, portanto o JDK 11 será neste ano e o próximo com o JDK 17, previsto para 2021.

Com a divulgação oficial da Oracle sobre os recursos do Java 11 a Oracle liberou o repositório mainline no diretório jdk/jdk11. As alterações enviadas para o jdk/jdk ou jdk/client agora são marcadas para o JDK 12. O repositório de estabilização pode aceitar correções de bugs selecionadas e, se aprovadas, aprimoramentos atrasados conforme o JDK Release Process.

Então vamos aos novos recursos do Java 11

  • Melhoramento dos instrisicos no Aarch64 – foram otimizadas as funções lang.Math sin, cos e log, para os processadores Aarch64. Esta proposta enfatiza padrões de código específicos da arquitetura de CPU especializados que melhoram o desempenho de aplicativos e benchmarks. Os intrínsecos são usados para aproveitar o código de montagem específico da arquitetura da CPU, que é executado em vez do código Java genérico para um determinado método para melhorar o desempenho. Embora a maioria dos intrínsecos já esteja implementada na porta AArch64, os intrínsecos otimizados para os métodos java.lang.Math ainda estavam ausentes.
  • Transport Layer Security (TLS) 1.3 – a nova revisão do protocolo TLS foi atualizada no JDK 11. Oferece benefícios significativos de segurança e desempenho. No entanto não há previsão de suportar todos os recursos do TLS 1.3. Para minimizar os riscos de incompatibilidade, o TLS 1.3 implementa o modo de compatibilidade com versões anteriores por padrão. As aplicações podem ativar ou desativar este modo conforme desejado. A versão final do TLS 1.3 foi publicada em Agosto de 2018. A parte interessante é que o TLS 1.3 inclui muitas melhorias de segurança e desempenho. Com a atualização do protocolo HTTP/2 no final de 2015 e agora com o TLS 1.3 em 2018, as conexões criptografadas estão mais seguras e mais rápidas do que nunca. Chrome e Firefox já dão suporte em sua última versão.
  • Deprecação do mecanismo de JavaScript da Nashorn, juntamente com a ferramenta JJS, com a intenção de removê-los no futuro. A Oracle achou complicado continuar dando suporte devido ao rápido desenvolvimento e geração de novas versões do Nashorn. O Nashorn é um mecanismo que foi lançado com o Java 8. O projeto foi anunciado primeiro no encontro de idiomas da JVM em julho de 2011 e depois confirmado no JavaOne em outubro de 2011.
  • HTTP Client (Versão Standard), que padroniza a API do HTTP Client que fora incubada no JDK 9 e atualizada no JDK 10. A API oferece semântica de solicitação e resposta sem bloqueio por meio de CompleteableFutures, que pode ser vinculada para disparar ações dependentes. A implementação, agora assíncrona, foi quase totalmente reescrita, depois da incubação nos JDKs 9 e 10. O conceito do RX Flow foi implementado nesta versão, eliminando muitos conceitos personalizados necessários para suportar o HTTP/2. O fluxo de dados agora pode ser rastreado com mais facilidade, de editores de solicitação no nível do usuário e editores de resposta ao soquete subjacente. Isso reduz a complexidade e maximiza a possibilidade de reutilização entre HTTP/1 e HTTP/2.
  • O Garbage Collector Epsilon, classificado como “não operacional”, manipula agora a alocação de memória sem implementar nenhum mecanismo de recuperação de memória real. Forneçe uma implementação de GC completamente passiva com um limite de alocação limitado e com sobrecarga de latência mais baixa possível, às custas do consumo de memória e da taxa de transferência de memória. Uma implementação bem-sucedida é uma alteração de código isolada, não toca em outros GCs e faz alterações mínimas no restante da JVM. Vale lembrar que o Java possui várias versões de Garbage Collector com diferentes propósitos.
  • Uma sintaxe de variável local para parâmetros Lambda deve alinhar a sintaxe de uma declaração de parâmetro formal em uma expressão digitada implicitamente com a sintaxe de uma declaração de variável local. Isso permitiria que var seja usado ao declarar parâmetros formais de expressões Lambda implicitamente tipadas.
    //expressão lambda digitada implícita
    (var x, var y) -> x.process(y)   
    
    //Um benefício da uniformidade é que os modificadores,
    //notavelmente as anotações, podem ser aplicados a 
    //variáveis locais e a lambda sem perder a brevidade:
    @Nonnull var x = new Foo();
    (@Nonnull var x, @Nullable var y) -> x.process(y)
    
  • O formato de arquivo de classe Java foi estendido para suportar um novo pool de constante, CONSTANT_Dynamic. Foi buscado com isso reduzir o custo e a interrupção da criação de novas formas de constantes de arquivo de classes materializable, o que, por sua vez, oferece aos arquitetos e designers de linguagem e aos implementadores de compiladores opções mais amplas de expressividade e desempenho. Isso foi feito criando um novo formulário de pool de constantes que pode ser parametrizado com o comportamento fornecido pelo usuário, na forma de um método de bootstrap com argumentos estáticos.
  • A concordância-chave com a criptografia Curve25519 e Curve448 deve ser mais eficiente e segura do que o esquema de curva elíptica Diffie-Hellman existente. A RFC 7748 define um esquema de acordo de chave que é mais eficiente e seguro do que o esquema de curva elíptica Diffie-Hellman (ECDH) existente. O principal objetivo deste PEC é uma API e uma implementação para este padrão. Metas adicionais de implementação são:
    • Desenvolver uma implementação totalmente independente de plataforma e Java com melhor desempenho do que o código ECC (C nativo) existente com a mesma segurança.
    • Assegurar que o tempo seja independente de segredos, supondo que a plataforma execute adição/multiplicação de inteiros de 64 bits em tempo constante. Além disso, a implementação não irá se ramificar em segredos. Essas propriedades são valiosas para evitar ataques de canal lateral.

    Há um risco, no entanto, na complexidade e sutileza da implementação aritmética modular apresentada como parte da proposta.

  • Inclusão do Flight Recorder. O Rastreamento de JVM Baseado em Evento incluiu um conjunto inicial de eventos na JVM do HotSpot. O Flight Recorder estenderá a capacidade de criar eventos para o Java. Também foi adicionado um backend rudimentar, onde os dados dos eventos são impressos no stdout. O Flight Recorder fornecerá um único back-end de alto desempenho para gravar eventos em um formato binário.
  • Upgrade das APIs da plataforma para suportar o Unicode Versão 10.0, com isso o Java fica atualizado com a última versão. O suporte é esperado nas seguintes classes:
    • Character e String no pacote lang
    • NumericShaper no pacote awt.font
    • Bidi, BreakIterator, e Normalizer no pacote text
  • Implementação dos algoritmos criptográficos ChaCha20 e Poly1305 como especificados na RFC 7539. ChaCha20 é uma cifra de fluxo relativamente nova que pode substituir a antiga cifra de fluxo RC4 considerada insegura. É consenso no mercado que o ChaCha20-Poly1305 é bastante seguro neste momento, e tem experimentado uma ampla adoção através de implementações de TLS, bem como em outros protocolos criptográficos. Com isso, a Oracle achou necessário deixar o JDK atualizado com outros toolkits criptográficos e implementações de TLS.
  • Aprimoramento o launcher do Java para executar um programa (executável) como um único arquivo de código-fonte Java, de modo que esses programas possam ser executados diretamente a partir do código-fonte. Programas de arquivo único são comuns ao escrever pequenos utilitários ou para desenvolvedores nos estágios iniciais de aprendizado do Java. Além disso, um único arquivo de origem pode ser compilado em vários arquivos de classe, o que adiciona sobrecarga de empacotamento. Nesses contextos, ter que compilar um programa antes de executá-lo é apenas um passo desnecessário baseado na tradição.
  • Perfil de heap de baixa sobrecarga, permitindo uma maneira de amostrar alocações de heap Java acessíveis por meio da Interface da Ferramenta JVM. O objetivo desse esforço é obter informações sobre essas alocações com baixo overhead. Pode ser acessado por meio de uma interface programática e pode amostrar todas as alocações. A independência da implementação e o fornecimento de dados sobre heaps ativos e mortos também fazem parte dos objetivos deste implementação. O gerenciamento inadequado de heap pode levar à exaustão de pilha e do GC. A maioria das ferramentas que lidam com isso não tem um set de chamadas para alocações específicas, informações que podem ser críticas para a depuração de problemas de memória.
  • Deprecação das ferramentas Pack200 e Unpack200 e da API Pack200 no util.jar. O Pack200 é um esquema de compactação para arquivos .jar, destinado a reduzir os requisitos de disco e largura de banda para empacotamento, transmissão e entrega de aplicativos. Os custos de manutenção e o baixo uso não justificam sua retenção, dizem os líderes do projeto.
  • Novo Z Garbage Collector (ZGC), um GC experimental de baixa latência, para lidar com pilhas que variam de pilhas relativamente pequenas a muito grandes, com muitos terabytes de tamanho. Usando o ZGC, os tempos de pausa não devem exceder 10ms e não deve haver mais de 15% de redução no throughput do aplicativo em comparação com o uso do coletor G1. O ZGC também estabelece uma base para recursos e otimizações futuras. Linux/x64 é a primeira plataforma a obter suporte a ZGC.

Conclusão

Com o novo ciclo de lançamento acelerado do Java, esperamos muitas mudanças nos próximos anos. Isso é muito positivo pois permitirá ao Java se manter sensível às tendências emergentes no desenvolvimento e às necessidades de seus usuários. Juntamente com o suporte estendido para construções de referência, significa que a Oracle implementou uma abordagem híbrida que obtém o melhor dos dois mundos em termos de estabilidade e flexibilidade. Estamos bastante otimistas com o futuro da linguagem.

*** A OctalMind é uma empresa especializada no desenvolvimento de sistemas de alta tecnologia.