JavaRush /Blogue Java /Random-PT /Java 14: o que há de novo?

Java 14: o que há de novo?

Publicado no grupo Random-PT
Os problemas do mundo são os problemas do mundo, e o novo Java está dentro do prazo. Ou seja, exatamente uma vez a cada seis meses. A versão de lançamento do Java 14 foi lançada em 17 de março e introduziu diversas inovações interessantes na linguagem voltada para desenvolvedores. Java 14: o que há de novo?  - 1Entre eles estão suporte experimental para a palavra-chave record , suporte para correspondência de padrões no operador " instanceof ", NullPointerExceptions mais fáceis de usar , "visualização" expandida de blocos de texto , uma opção padrão atualizada e muito mais. Lembramos que todas as inovações em Java começam com propostas de extensão ( JEP, Java Enhancement Proposals ). Os desenvolvedores propõem alterações, elas são revisadas pelos pais “oficiais” do Java e, então, algumas dessas alterações são aceitas, após o que se tornam parte do JDK. E agora - tudo em ordem.

JEP 359: Registros

Records, também conhecidos como Records, estão disponíveis para JDK 14 em modo de visualização, e isso é algo completamente novo para Java. Na verdade, temos diante de nós um novo tipo que foi desenvolvido durante o projeto Valhalla . Os registros são semelhantes às enumerações e permitem simplificar seu código. Essencialmente, eles substituem classes que possuem estado, mas nenhum comportamento. Simplificando, existem campos, não métodos. No caso de classes, às vezes temos que escrever muito código repetitivo que nem sempre é necessário: construtores, acessadores, equals(), hashCode(), toString(), etc. para usar o registro. Aqui está a versão clássica:
final class Triangle {
 	public final int x;
public final int y;
public final int z;

    public Triangle(int x, int y, int z) {
         this.x = x;
         this.y = y;
    this.z = z;
    }
    // equals, hashCode, toString
Vamos passar para o Java 14 e usar o registro:
public record Triangle(int x, int y, int z){}
Isso é tudo. Observe que as gravações atualmente existem em formato de visualização, portanto, para experimentá-las na prática, você precisa baixar o jdk14 e digitar o comando:
javac —enable-preview —release 14 Triangle.java
Os registros são aulas, embora com limitações. Eles não podem estender outras classes ou declarar campos (exceto private final que correspondem a componentes de declaração de estado). Os registros são implicitamente finais e não podem ser abstratos. Os registros diferem das classes regulares porque não podem separar sua API de sua representação. Mas a perda de liberdade é compensada pelo aumento da precisão. Os componentes de registro também são implicitamente finais.

JEP 305: correspondência de padrões para instanceof (visualização)

O recurso Pattern Matching , introduzido no Java 14 na visualização, foi projetado para combinar a verificação do tipo de um objeto e sua conversão no operador instanceof . Em outras palavras, antes do Java 14 existiria, por exemplo, o seguinte código:
Object object = Violin;

if (object instanceof Instrument) {
    Instrument instrument = (Instrument) object;
    System.out.println(instrument.getMaster());
}
Como você pode ver, devemos converter o objeto para a classe cujos métodos queremos usar. Agora o Java 14 e o recurso Pattern Matching conectado permitem reduzir o código ao seguinte:
Object object = Violin;

if (object instanceof Instrument instrument){
    System.out.println(instrument.getMaster());
}

JEP 343: Ferramenta de Embalagem (Incubadora)

O JDK 8 tinha uma ferramenta javapackager projetada para JavaFX. No entanto, após a separação do JavaFX do Java com o lançamento do JDK 11, o popular javapackager não estava mais disponível. Javapackager era uma ferramenta de empacotamento. Permitiu que os aplicativos Java fossem empacotados de tal forma que pudessem ser instalados como todos os outros programas “normais”. Por exemplo, crie arquivos exe para usuários do Windows e inicie um aplicativo Java como um ser humano - com um clique duplo. É claro que tal ferramenta está faltando, então o JEP 343 introduziu uma nova ferramenta, jpackage , que empacota um aplicativo Java em um pacote específico da plataforma contendo todas as dependências necessárias. Formatos de pacote suportados para uma plataforma específica:
  • Linux: deb e rpm
  • macOS: pacote e dmg
  • Windows: MSI e EXE

JEP 345: Alocação de memória compatível com NUMA para G1

JEP 345 serve apenas para implementar suporte a NUMA (acesso não uniforme à memória). São arquiteturas heterogêneas de acesso à memória, uma forma de configurar um cluster de microprocessadores em um sistema multiprocessador no qual a memória pode ser distribuída localmente: cada núcleo do processador obtém uma pequena quantidade de memória local, enquanto outros núcleos têm acesso a ela. O JEP 345 planeja equipar o coletor de lixo G1 com a capacidade de aproveitar tais arquiteturas. Entre outras coisas, esta abordagem ajuda a melhorar o desempenho em máquinas muito potentes.

JEP 349: Transmissão de eventos JFR

Java Flight Recorder (JFR) agora faz parte do OpenJDK e, portanto, está disponível gratuitamente. O JDK 14 adiciona uma API para rastreamento instantâneo de eventos JFR (JDK Flight Recorder), em particular para organizar o monitoramento contínuo de aplicativos ativos e inativos. Os mesmos eventos são registrados na opção sem streaming, com uma sobrecarga inferior a 1%. Desta forma, os eventos serão transmitidos ao mesmo tempo que a opção sem streaming. Contudo, o JEP 349 não deve permitir retornos de chamada síncronos para o consumidor correspondente. Mesmo os dados dos registros armazenados na memória intermediária não deveriam estar acessíveis. Tecnicamente, o pacote jdk.jfr.consumer no módulo jdk.jfr será estendido com funcionalidade para acesso assíncrono a eventos.

JEP 352: Buffers de bytes mapeados não voláteis

Como sabemos, a API de arquivo Java NIO (New IO) existe desde o JDK 1.4 e, em seguida, um novo aprimoramento chamado Path foi introduzido. Path é uma interface que substitui a classe java.io.File como representação de um arquivo ou diretório quando trabalhamos em Java NIO. JEP 352 estende MappedByteBuffer para carregar uma parte dos dados do arquivo na memória não volátil (NVM). Esta memória do computador, na qual os dados não serão perdidos mesmo se a energia for desligada (geralmente chamada de memória somente leitura), é usada para armazenar dados permanentemente. Esta proposta de melhoria Java fornece um novo módulo e classe para a API JDK: o módulo jdk.nio.mapmode, que oferece novos modos (READ_ONLY_SYNC, WRITE_ONLY_SYNC) para criação de buffers de bytes mapeados (MappedByteBuffer) referenciando NVM.

JEP 358: NullPointerExceptions úteis

NullPointerExceptions agora será mais amigável ao programador. No sentido de que a descrição da exceção será muito mais informativa do que antes. Isso ocorre porque a JVM foi ensinada a analisar com mais precisão as instruções de bytecode do programa e pode indicar qual variável leva a um valor zero. Digamos que temos o código:
a.getMessage().getUserInfo().getName()
Em qualquer um dos Java mais recentes, obteremos o log de erros usual, que não responde à questão de quem exatamente é nulo:
Exception in thread "main" java.lang.NullPointerException
	at Main.main(Main.java:12)
E aqui está o que o Java 14 lhe dará se você decidir experimentar este recurso de visualização:
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "UserInfo().getName()" because the return value of "Message().getUserInfo()" is null
	at Main.main(Main.java:12)
Essa cadeia é muito mais compreensível e permite solucionar o erro com muito mais rapidez.

JEP 361: Alternar Expressões (Padrão)

O operador Switch atualizado estava disponível no Java 12 e 13 anteriores, mas apenas como um recurso de visualização, ou seja, não estava habilitado por padrão. Agora, no JDK 14, tudo funciona imediatamente. Java 14 introduz uma nova forma simplificada do bloco switch com rótulos case L -> .... A nova forma simplifica o código em alguns casos. Aqui estão alguns exemplos. Digamos que temos um enum que descreve os dias da semana. Podemos escrever código clássico (pré-Java 14):
switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}
E aqui está uma opção usando Java 14:
switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}
Você também pode escrever blocos multilinhas e retornar um valor com a nova palavra-chave yield:
int result = switch (s) {
    case "Working from Home" -> 1;
    case "Working from Office" -> 2;
    default    -> {
        System.out.println("Neither Home nor Office… Cafe? Car? Park?...");
        yield 0;
    }
};
Há mais algumas coisas importantes que você deve ter em mente ao usar os novos switches . Em particular, é preciso lembrar que as opções devem ser exaustivas. Ou seja, para todos os valores possíveis deve haver um rótulo de switch correspondente. Como rendimento agora é uma palavra-chave, uma classe chamada rendimento é possível no Java 14. Em geral, se você quiser aprender como usar as opções atualizadas, vá para JEP 361 e estude. Há muitas informações interessantes lá.

JEP 362: Descontinuar as portas Solaris e SPARC

É improvável que muitos de nossos leitores se lembrem do sistema operacional Solaris . Este sistema operacional baseado em UNIX, criado pelos pais do Java, Sun Microsystems, foi usado principalmente para servidores na arquitetura SPARC... Muitas palavras desconhecidas por centímetro quadrado? Não é grande coisa: o JEP 362 encerra o suporte para as plataformas Solaris/SPARC, Solaris/x64 e Linux/SPARC. Ou seja, suas portas agora estão obsoletas e, no futuro, provavelmente serão removidas do OpenJDK. No entanto, versões mais antigas do Java (anteriores ao JDK 14) relativas às portas Solaris/SPARC, Solaris/x64 e Linux/SPARC devem funcionar sem modificação. Se você é fã de história e está interessado em tecnologias de um passado não tão distante, acesse a Wikipedia e leia sobre a arquitetura SPARС .

JEP 363: Remover o coletor de lixo de varredura de marca simultânea (CMS)

O coletor de lixo CMS (Concurrent Mark Sweep) deve ser removido porque há dois anos foi marcado como obsoleto e não foi mantido. No entanto, os usuários de versões mais antigas do Java que usam o CMS GC podem expirar - o objetivo deste JEP não é remover o construtor de versões anteriores do JDK. Além disso, a combinação dos algoritmos de coleta de lixo ParallelScavenge e SerialOld (executando com as opções "-XX:+UseParallelGC -XX:-UseParallelOldGC") foi descontinuada.

JEP 364: ZGC no macOS e JEP 365: ZGC no Windows

Existe um coletor de lixo interessante chamado Z Garbage Collector (ZGC) . Funciona em modo passivo e tenta minimizar atrasos devido à coleta de lixo: o tempo de parada ao usar ZGC não ultrapassa 10 ms. Pode funcionar com heaps pequenos e gigantes (aqueles que ocupam muitos terabytes). JEP 364 e JEP 365 são praticamente gêmeos. JEP 364 traz o Z ​​Garbage Collector para MacOS. Parte do JEP também descreve a funcionalidade do coletor para liberar memória não utilizada do dispositivo, conforme especificado no JEP 351 , isso ocorre com Java 13. A implementação do ZGC no macOS consiste em duas partes:
  • Suporte de memória multimapeamento no macOS
  • Suporte ZGC para reserva contínua de memória
JEP 365 oferece suporte para ZGC já no Windows, e também em modo experimental. É o seguinte:
  • Suporte de memória multi-mapeamento
  • Suporte para mapeamento de memória baseado no arquivo de paginação em um espaço de endereço reservado
  • Suporte para mapeamento e desmapeamento de partes arbitrárias do heap
  • Suporte para confirmar e descomprometer partes arbitrárias do heap

JEP 366: descontinuar a combinação ParallelScavenge + SerialOld GC

Este JEP descontinua a combinação dos algoritmos de coleta de lixo Parallel Scavenge e Serial Old. Esta combinação teve que ser habilitada manualmente usando os parâmetros de linha de comando -XX: + UseParallelGC -XX: -UseParallelOldGC. Os autores acreditam que a combinação é muito específica, mas também requer um esforço significativo de manutenção. Portanto, agora a opção -XX: UseParallelOldGC está obsoleta e um aviso aparecerá se for usado.

JEP 367: Remover as ferramentas e API Pack200

Pack200 é um formato de arquivo otimizado para armazenar arquivos de classe Java compilados. Esta ferramenta foi marcada como obsoleta desde Java 11. Agora as ferramentas API pack200, unpack200 e Pack200 foram oficialmente anunciadas para remoção do pacote java.util.jar . Essa tecnologia foi introduzida no Java 5 como um meio de lidar com largura de banda muito limitada (modems, é assustador dizer e lembrar, 56k) e espaço de armazenamento insuficiente em discos rígidos. Há algum tempo, o Java 9 introduziu novos esquemas de compactação. Os desenvolvedores são incentivados a usar jlink .

JEP 368: Blocos de texto (segunda visualização)

Os blocos de texto apareceram pela primeira vez em Java 13. Eles são literais de string multilinha que evitam a necessidade da maioria das sequências de escape, formatam automaticamente a string e também permitem que o desenvolvedor formate a string, se necessário. Este recurso útil agora está disponível no Java 14 (2ª visualização). O principal objetivo dos blocos de texto é melhorar o tratamento de literais confusos de múltiplas linhas. Isso simplifica muito a leitura e gravação de consultas SQL, código HTML e XML e JSON. Exemplo de HTML sem blocos de texto:
String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Hello, JavaRush Student</p>\n" +
              "    </body>\n" +
              "</html>\n";
Como representar o mesmo com blocos de texto:
String html = """
              <html>
                  <body>
                      <p>Hello, JavaRush Student</p>
                  </body>
              </html>
              """;
O delimitador de abertura é uma sequência de três caracteres de aspas duplas ("" "), seguidos por zero ou mais espaços e, em seguida, um delimitador de linha. O conteúdo começa no primeiro caractere após o delimitador de linha do delimitador de abertura. O delimitador de fechamento é uma sequência de três caracteres de aspas duplas " _ ) foi escolhida para que os caracteres pudessem ser exibidos sem escape, e também distinguir visualmente um bloco de texto de uma string literal. No início de 2019, o JEP 355 propôs blocos de texto como uma continuação do JEP 326 (literais Raw String), mas eles foram retirados. Mais tarde naquele ano, o JDK 13 introduziu o recurso de visualização de bloco de texto e agora o Java 14 adicionou duas novas sequências de escape. Este é um terminador de linha, denotado por \, e o segundo é para espaço único, denotado por /s. Um exemplo de uso de novas linhas sem blocos de texto:
String literal = "This is major Tom to Ground Control " +
"I am stepping through the door... " +
"Wait… What???";
E agora com a sequência de escape \<line-terminator>:
String text = """
                This is major Tom to Ground Control \
                I am stepping through the door... \
                WaitWhat???\
                """;
A sequência de escape \s é usada para contabilizar os espaços em branco à direita, que são ignorados pelo compilador por padrão. Preserva todos os espaços em branco que o precedem. Exemplo:
String text1 = """
               line1
               line2 \s
               line3
               """;

String text2 = "line1\nline2 \nline3\n";
text1e text2são idênticos.

JEP 370: API de acesso à memória externa (incubadora)

Muitas bibliotecas e programas Java populares têm acesso à memória externa. Por exemplo, API Ignite, MapDB, Memcached e Netty ByteBuf. Ao fazer isso, eles podem evitar o custo e a imprevisibilidade associados à coleta de lixo (especialmente ao servir caches grandes), compartilhar memória entre vários processos e serializar e desserializar o conteúdo da memória mapeando arquivos na memória (por exemplo, usando mmap). Porém, a API Java ainda não possui uma solução adequada para acesso à memória externa. O JDK 14 inclui uma visualização da API de acesso à memória externa , que permite que aplicativos Java acessem regiões de memória fora do heap JVM de forma segura e eficiente usando as novas abstrações MemorySegment, MemoryAddress e MemoryLayout.

conclusões

Então, o que você acha? Comparado ao Java 13, o novo Java 14 oferece muitas melhorias mais importantes em diversas áreas. Provavelmente, o mais importante para os desenvolvedores será a opção atualizada, exceções estendidas NullPointerExceptions e registros. Ou não?.. Não se esqueça de experimentar os novos recursos do Java 14, é muito útil até para iniciantes. Boa sorte com seus estudos!
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION