Após seis meses de desenvolvimento, a Oracle lançou plataforma Java SE 15 (Java Platform, Standard Edition 15), cuja implementação de referência é o projeto aberto OpenJDK. O Java SE 15 mantém a compatibilidade reversa com as versões anteriores da plataforma Java, todos os projetos Java escritos anteriormente funcionarão sem modificações ao serem executados na nova versão. Compilações prontas para instalação do Java SE 15 (JDK, JRE e Server JRE) foram preparados para Linux (x86_64), Windows e macOS. A implementação de referência desenvolvida no âmbito do projeto OpenJDK Java 15 é totalmente aberta sob a licença GPLv2 com exceções do GNU ClassPath, permitindo ligação dinâmica a produtos comerciais.

Java SE 15 é classificado como uma versão de suporte padrão, com atualizações sendo lançadas até o próximo lançamento. Para uma versão com suporte a longo prazo (LTS), deve-se utilizar o Java SE 11, com atualizações sendo lançadas até 2026. A versão LTS anterior, Java 8, será suportada até dezembro de 2020. O próximo lançamento LTS está previsto para setembro de 2021. Lembre-se de que, a partir do lançamento do Java 10, o projeto adotou um novo processo de desenvolvimento, que prevê um ciclo mais curto para novas versões. A nova funcionalidade agora é desenvolvida em uma ramificação master constantemente atualizada, que incorpora mudanças já concluídas e da qual são ramificadas versões para estabilização a cada seis meses.

De novidades Java 15 é possível marcar:

• Integrado suporte para o algoritmo de criação de assinatura digital EdDSA (Edwards-Curve Digital Signature Algorithm RFC 8032). A implementação proposta do EdDSA não depende de plataformas de hardware, é protegida contra ataques de canal lateral (garantindo tempo constante em todos os cálculos) e, em termos de desempenho, supera a implementação existente do ECDSA, escrita na linguagem C, com o mesmo nível de proteção. Por exemplo, o EdDSA usando uma curva elíptica com uma chave de 126 bits demonstra desempenho semelhante ao ECDSA com a curva elíptica secp256r1 e uma chave de 128 bits.
• Adicionada suporte experimental para classes e interfaces 'sealed', que não podem ser utilizadas por outras classes e interfaces para herdar, estender ou sobrescrever a implementação. Classes seladas também fornecem uma maneira mais declarativa de restringir o uso da superclasse, em comparação com modificadores de acesso, que se baseiam na enumeração explícita das subclasses permitidas para extensão.

  package com.example.geometry;

  public sealed class Shape
  permits com.example.polar.Circle,
  com.example.quad.Rectangle,
  com.example.quad.simple.Square {…}

• Adicionada suporte a classes ocultas que não podem ser usadas diretamente pelo bytecode de outras classes. O principal objetivo das classes ocultas é seu uso em frameworks que geram classes dinamicamente em tempo de execução e as utilizam indiretamente, através de reflexão. Essas classes geralmente têm um ciclo de vida limitado, portanto, mantê-las para acesso a partir de classes geradas estaticamente não é justificável e resultará apenas em aumento do consumo de memória. Classes ocultas também permitem contornar a API não padrão sun.misc.Unsafe::defineAnonymousClass, que está programada para ser removida no futuro.
• O coletor de lixo ZGC (Z Garbage Collector) foi estabilizado e reconhecido como pronto para uso generalizado. O ZGC opera no modo passivo, minimizando, tanto quanto possível, as interrupções causadas pela coleta de lixo (o tempo de parada ao usar o ZGC não excede 10 ms) e pode trabalhar com heaps pequenos ou enormes, variando de algumas centenas de megabytes a vários terabytes.
• Estabilizado e reconhecido como pronto para uso generalizado
  coletor de lixo Shenandoah, que opera com interrupções mínimas (Low-Pause-Time Garbage Collector). O Shenandoah foi desenvolvido pela Red Hat e é notável por usar um algoritmo que reduz o tempo de paradas durante a coleta de lixo, realizando a limpeza paralelamente à execução de aplicativos Java. O tamanho das interrupções causadas pelo coletor de lixo é previsível e não depende do tamanho do heap, ou seja, para heaps de 200 MB e 200 GB, os atrasos serão idênticos (não ultrapassando 50 ms e geralmente se enquadrando em 10 ms);
• Foi estabilizada e adicionada ao idioma a suporte a blocos de texto — uma nova forma de literais de string, permitindo incluir dados de texto multilinhas no código-fonte sem aplicar escape de caracteres e mantendo a formatação original do texto em bloco. O bloco é delimitado por três aspas duplas.

  Por exemplo, em vez de código

  String html = "" +
  "\n\t" + "" +
  «\n\t\t» + «

  "Java 15 chegou!"

  » +
  "\n\t" + "" +
  "\n" + "";

  pode-se indicar:

  String html = """
  <HTML>
  <BODY>
  

  "Java 15\
  chegou!"
  <\/BODY>
  """;

• Revisado API Legacy DatagramSocket. As antigas implementações java.net.DatagramSocket e java.net.MulticastSocket foram substituídas por uma implementação moderna, mais simples para depuração e manutenção, além de ser compatível com fluxos virtuais em desenvolvimento no projeto Loom. Em caso de possível incompatibilidade com o código existente, a antiga implementação não foi removida e pode ser ativada através da opção jdk.net.usePlainDatagramSocketImpl.
• Uma segunda implementação experimental foi proposta correspondências com o modelo na operação «instanceof», que permite determinar imediatamente uma variável local para acessar o valor verificado. Por exemplo, pode-se escrever imediatamente «if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}» sem definir explicitamente «String s = (String) obj».

  Era:

  if (obj instanceof Group) {
  Group group = (Group) obj;
  var entries = group.getEntries();
  }

  Agora é possível evitar a definição «Group group = (Group) obj»:

  if (obj instanceof Group group) {
  var entries = group.getEntries();
  }

• Proposta a segundo a implementação experimental da palavra-chave “record», que fornece uma forma compacta para definir classes, permitindo evitar a definição explícita de vários métodos de baixo nível, como equals(), hashCode() e toString(), em casos onde os dados são armazenados apenas em campos, cujo comportamento não muda. Quando implementações de métodos como equals(), hashCode() e toString() são usadas na classe, pode-se evitar sua definição explícita:

  registro público BankTransaction(LocalDate data,
  double valor,
  String descrição) {}

  Esta declaração resultará na adição automática das implementações dos métodos equals(), hashCode() e toString() além do construtor e dos métodos que controlam a modificação de dados (getter).

• Proposto segunda versão preliminar da API de Acesso à Memória Estrangeira, permitindo que aplicações Java acessem de forma segura e eficiente áreas de memória fora do heap Java, manipulando novas abstrações MemorySegment, MemoryAddress e MemoryLayout.
• Desativado e a técnica de otimização Biased Locking foi declarada obsoleta, utilizada no HotSpot JVM para reduzir as despesas com bloqueios. Esta técnica se tornou obsoleta em sistemas com instruções atômicas, fornecidas por CPUs modernas, e é muito trabalhosa para manutenção devido à sua complexidade.
• Anunciado mecanismo obsoleto Ativação RMI, que será removido em uma das próximas versões. Vale ressaltar que a Ativação RMI se tornou obsoleta, sendo transformada em uma opção desde o Java 8 e quase não sendo utilizada na prática moderna.
• Removido motor JavaScript Nashorn, que foi declarado obsoleto no Java SE 11.
• método não padrão portas para o sistema operacional Solaris e processadores SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). A remoção das portas mencionadas permitirá que a comunidade acelere o desenvolvimento de novas funcionalidades do OpenJDK, sem perder tempo na manutenção de particularidades específicas para Solaris e SPARC.

Fonte: opennet.ru