Dopo sei mesi di sviluppo, Oracle la piattaforma (Java Platform, Standard Edition 15), la cui implementazione di riferimento è un progetto open source OpenJDK. In Java SE 15 è mantenuta la retrocompatibilità con le versioni precedenti della piattaforma Java, tutti i progetti Java precedentemente scritti funzioneranno senza modifiche con la nuova versione. Le versioni pronte per l'installazione di Java SE 15 (JDK, JRE e Server JRE) per Linux (x86_64), Windows e macOS. L'implementazione di riferimento sviluppata nel progetto OpenJDK è completamente open source sotto la licenza GPLv2 con eccezioni GNU ClassPath, che consentono il collegamento dinamico con prodotti commerciali.
Java SE 15 è classificato come una versione con supporto standard, con aggiornamenti previsti fino al prossimo rilascio. Per una versione con supporto a lungo termine (LTS), si consiglia di utilizzare Java SE 11, i cui aggiornamenti saranno disponibili fino al 2026. La precedente versione LTS, Java 8, sarà supportata fino a dicembre 2020. Il prossimo rilascio LTS è previsto per settembre 2021. Ricordiamo che a partire da Java 10, il progetto ha adottato un nuovo processo di sviluppo, caratterizzato da cicli di rilascio più brevi. Le nuove funzionalità vengono ora sviluppate in un ramo master costantemente aggiornato, in cui vengono integrate le modifiche già pronte, dalle quali si diramano rami per stabilizzare i nuovi rilasci ogni sei mesi.
Da :
- supporto per l'algoritmo di creazione della firma digitale EdDSA (Edwards-Curve Digital Signature Algorithm ). L'implementazione proposta di EdDSA non dipende dalle piattaforme hardware, è protetta da attacchi tramite canali laterali (garantendo un tempo costante per tutti i calcoli) e supera in prestazioni l'attuale implementazione di ECDSA scritta in C, mantenendo lo stesso livello di sicurezza. Ad esempio, EdDSA, utilizzando una curva ellittica con una chiave a 126 bit, dimostra prestazioni simili a ECDSA con la curva ellittica secp256r1 e una chiave a 128 bit.
- supporto sperimentale per classi e interfacce sigillate («sealed») che non possono essere utilizzate da altre classi e interfacce per ereditare, estendere o sovrascrivere l'implementazione. Le classi sigillate forniscono anche un modo più dichiarativo per limitare l'uso della superclasse rispetto ai modificatori di accesso, basato su un'esplicita enumerazione delle sottoclassi autorizzate per l'estensione.
package com.example.geometry;
public sealed class Shape
permits com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - supporto per classi nascoste, che non possono essere utilizzate direttamente dal bytecode di altre classi. L'uso principale delle classi nascoste è quello di essere utilizzate in framework che generano dinamicamente classi durante l'esecuzione e le utilizzano indirettamente, tramite . Tali classi hanno generalmente un ciclo di vita limitato, quindi mantenerle per l'accesso da classi generate staticamente non è giustificato e porterà solo a un aumento del consumo di memoria. Le classi nascoste consentono anche di evitare l'uso dell'API non standard sun.misc.Unsafe::defineAnonymousClass, che è prevista per la rimozione in futuro.
- Stabilizzato e riconosciuto pronto per l'uso generale il garbage collector ZGC (Z Garbage Collector). ZGC opera in modalità passiva, riducendo al minimo i ritardi dovuti alla raccolta dei rifiuti (il tempo di arresto quando si utilizza ZGC non supera i 10 ms) e può funzionare sia con piccole che con enormi heap, con dimensioni che vanno da alcune centinaia di megabyte a diversi terabyte.
- Stabilizzato e riconosciuto pronto per l'uso generale
garbage collector , in grado di funzionare con pause minime (Low-Pause-Time Garbage Collector). Shenandoah è stato sviluppato da Red Hat ed è noto per l'uso di un algoritmo che riduce il tempo di pausa durante la raccolta dei rifiuti eseguendo la pulizia in parallelo con l'esecuzione delle applicazioni Java. Il ritardo causato dal garbage collector è prevedibile e non dipende dalla dimensione dell'heap, cioè per heap di 200 MB e 200 GB i ritardi saranno identici ( i 50 ms e di solito rientrano in 10 ms); - Stabilita e introdotta nel linguaggio la supporto — una nuova forma di letterali stringa che consente di includere nei codici sorgente dati testuali multilinea senza utilizzare l'escaping dei caratteri e mantenendo il formato originale del testo nel blocco. Il blocco è racchiuso da tre virgolette doppie.
Ad esempio, invece del codice
String html = "<HTML>" +
"\n\t" + "<BODY>" +
"\n\t\t" + "<H1>\"Java 15 is here!\"</H1>" +
"\n\t" + "</BODY>" +
"\n" + "</HTML>";si può specificare:
String html = """
<HTML>
<BODY>
<H1>"Java 15\
è qui!"</H1>
</BODY>
</HTML>"""; - API Legacy DatagramSocket. Le vecchie implementazioni di java.net.DatagramSocket e java.net.MulticastSocket sono state sostituite con un'implementazione moderna, più semplice da debug e mantenere, oltre a essere compatibile con i flussi virtuali in fase di sviluppo nel progetto. . Per evitare possibili problemi di compatibilità con il codice esistente, la vecchia implementazione non è stata rimossa e può essere attivata tramite l'opzione jdk.net.usePlainDatagramSocketImpl.
- Proposta di una seconda implementazione sperimentale nell'operatore «instanceof», che consente di definire immediatamente una variabile locale per accedere al valore verificato. Ad esempio, si può scrivere direttamente «if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}» senza la necessità di definire esplicitamente «String s = (String) obj».
Era:
if (obj instanceof Group) {
Group group = (Group) obj;
var entries = group.getEntries();
}Ora è possibile evitare la definizione «Group group = (Group) obj»:
if (obj instanceof Group group) {
var entries = group.getEntries();
} - seconda implementazione sperimentale della parola chiave ««, che fornisce una forma compatta per definire le classi, consentendo di fare a meno della definizione esplicita di vari metodi a basso livello come equals(), hashCode() e toString(), nei casi in cui i dati vengono memorizzati solo nei campi, il cui comportamento non cambia. Quando in una classe vengono utilizzate implementazioni generiche dei metodi equals(), hashCode() e toString(), è possibile evitarne la definizione esplicita:
public record BankTransaction(LocalDate date,
double amount,
String description) {}Questa dichiarazione porterà all'aggiunta automatica delle implementazioni dei metodi equals(), hashCode() e toString() oltre al costruttore e ai metodi che controllano la modifica dei dati (getter).
- il secondo prototipo dell'API Foreign-Memory Access, che consente alle applicazioni Java di accedere in modo sicuro ed efficiente a aree di memoria al di fuori dell'heap Java, manipolando le nuove astrazioni MemorySegment, MemoryAddress e MemoryLayout.
- e viene dichiarato obsoleto il meccanismo di ottimizzazione Biased Locking, utilizzato nella HotSpot JVM per ridurre le spese generali legate ai lock. Questo meccanismo è diventato irrilevante sui sistemi con istruzioni atomiche fornite dai moderni CPU e troppo complesso da mantenere a causa della sua complessità.
- obsoleto il meccanismo , che sarà rimosso in una delle prossime versioni. Si segnala che RMI Activation è obsoleto, declassato a opzione già in Java 8 e praticamente non utilizzato nella pratica moderna.
- motore JavaScript , che è stato dichiarato obsoleto in Java SE 11.
- porte per il sistema operativo Solaris e i processori SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). La rimozione di queste porte consentirà alla comunità di accelerare lo sviluppo di nuove funzionalità di OpenJDK, senza sprecare tempo a mantenere specificità legate a Solaris e SPARC.
Fonte: opennet.ru
