Após seis meses de desenvolvimento, a Oracle uma plataforma (Java Platform, Standard Edition 15), o projeto OpenJDK de código aberto é usado como implementação de referência. Java SE 15 mantém compatibilidade retroativa com versões anteriores da plataforma Java; todos os projetos Java escritos anteriormente funcionarão sem alterações quando lançados na nova versão. Compilações Java SE 15 prontas para instalar (JDK, JRE e Server JRE) para Linux (x86_64), Windows e macOS. Implementação de referência desenvolvida pelo projeto OpenJDK é totalmente de código aberto sob a licença GPLv2, com exceções GNU ClassPath permitindo vinculação dinâmica com produtos comerciais.
O Java SE 15 é classificado como uma versão de suporte geral e continuará recebendo atualizações até a próxima versão. O branch Long Term Support (LTS) deverá ser o Java SE 11, que continuará recebendo atualizações até 2026. A ramificação LTS anterior do Java 8 terá suporte até dezembro de 2020. O próximo lançamento LTS está agendado para setembro de 2021. Lembramos que a partir do lançamento do Java 10, o projeto passou para um novo processo de desenvolvimento, implicando em um ciclo mais curto para a formação de novos lançamentos. A nova funcionalidade agora é desenvolvida em um branch master constantemente atualizado, que inclui alterações prontas e a partir do qual os branchs são ramificados a cada seis meses para estabilizar novos lançamentos.
De :
- suporte para o algoritmo de criação de assinatura digital EdDSA (Edwards-Curve Digital Signature Algorithm) ). A implementação EdDSA proposta não depende de plataformas de hardware, é protegida contra ataques de canal lateral (é garantido o tempo constante de todos os cálculos) e tem desempenho mais rápido do que a implementação ECDSA existente escrita em linguagem C, com o mesmo nível de proteção. Por exemplo, EdDSA usando uma curva elíptica com uma chave de 126 bits exibe desempenho semelhante ao ECDSA com uma curva elíptica secp256r1 e uma chave de 128 bits.
- suporte experimental para classes e interfaces seladas, que não podem ser usadas por outras classes e interfaces para herdar, estender ou substituir a implementação. As classes seladas também fornecem uma maneira mais declarativa de restringir o uso de uma superclasse do que os modificadores de acesso, com base na lista explícita das subclasses permitidas para extensão.
pacote com.example.geometry;
classe pública selada Forma
permite com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - suporte para classes ocultas que não podem ser utilizadas diretamente pelo bytecode de outras classes. O objetivo principal das classes ocultas é ser usado em frameworks que geram classes dinamicamente em tempo de execução e as utilizam indiretamente, por meio de . Tais classes geralmente têm um ciclo de vida limitado, portanto, mantê-las para acesso a partir de classes geradas estaticamente não se justifica e só levará ao aumento do consumo de memória. As classes ocultas também eliminam a necessidade da API não padrão sun.misc.Unsafe::defineAnonymousClass, que está prevista para remoção 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, minimiza ao máximo a latência devido à coleta de lixo (o tempo de parada ao usar o ZGC não excede 10 ms) e pode trabalhar com heaps pequenos e enormes, variando em tamanho de várias centenas de megabytes a muitos terabytes.
- Estabilizado e encontrado pronto para uso geral
coletor de lixo , trabalhando com pausas mínimas (Low-Pause-Time Garbage Collector). Shenandoah foi desenvolvido pela Red Hat e se destaca pelo uso de um algoritmo que reduz o tempo de parada durante a coleta de lixo, executando a limpeza em paralelo com a execução de aplicativos Java. O tamanho dos atrasos introduzidos pelo coletor de lixo é previsível e não depende do tamanho do heap, ou seja, para pilhas de 200 MB e 200 GB os atrasos serão idênticos ( além de 50 ms e geralmente dentro de 10 ms); - O suporte foi estabilizado e introduzido no idioma - uma nova forma de literais de string que permite incluir dados de texto de várias linhas no código-fonte sem usar escape de caracteres e preservar a formatação do texto original no bloco. O bloco é enquadrado por três aspas duplas.
Por exemplo, em vez de código
Stringhtml = " » +
"\n\t" + " » +
"\n\t\t" + " \"Java 1 chegou!\" » +
"\n\t" + " » +
"\n" + " ";você pode especificar:
Stringhtml = """
»Java 1\
é aqui!
"""; - API DatagramSocket legada. As antigas implementações de java.net.DatagramSocket e java.net.MulticastSocket foram substituídas por uma implementação moderna que é mais fácil de depurar e manter, e também é compatível com fluxos virtuais desenvolvidos dentro do projeto . Em caso de possível incompatibilidade com o código existente, a implementação antiga não foi removida e pode ser habilitada usando a opção jdk.net.usePlainDatagramSocketImpl.
- Segunda implementação experimental proposta no operador “instanceof”, que permite definir imediatamente uma variável local para acessar o valor verificado. Por exemplo, você pode escrever imediatamente “if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}” sem definir explicitamente “String s = (String) obj”.
Foi:
if (obj instância do grupo) {
Grupo grupo = (Grupo) obj;
var entradas = group.getEntries();
}Agora você pode dispensar a definição “Group group = (Group) obj”:
if (obj instância do grupo de grupo) {
var entradas = group.getEntries();
} - segunda implementação experimental da palavra-chave "", 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 uma classe usa implementações padrão dos métodos equals(), hashCode() e toString(), ela pode prescindir de sua definição explícita:
registro público BankTransaction (data LocalDate,
quantidade dupla
Descrição da string) {}Esta declaração adicionará automaticamente implementações dos métodos equals(), hashCode() e toString() além dos métodos construtor e getter.
- uma segunda visualização da API de acesso à memória externa, permitindo que aplicativos Java acessem regiões de memória fora do heap Java de forma segura e eficiente, manipulando as novas abstrações MemorySegment, MemoryAddress e MemoryLayout.
- e descontinuado a técnica de otimização Biased Locking usada no HotSpot JVM para reduzir a sobrecarga de bloqueio. Esta técnica perdeu sua relevância em sistemas com instruções atômicas fornecidas por CPUs modernas e é muito trabalhosa para manter devido à sua complexidade.
- mecanismo desatualizado , que será removido em uma versão futura. Observa-se que a ativação RMI está desatualizada, relegada à categoria de opção no Java 8 e quase nunca é usada na prática moderna.
- Mecanismo JavaScript , que foi descontinuado no Java SE 11.
- portas para processadores Solaris OS e SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). A remoção dessas portas permitirá que a comunidade acelere o desenvolvimento de novos recursos OpenJDK sem perder tempo mantendo recursos específicos do Solaris e SPARC.
Fonte: opennet.ru