🥇Rilascio di Java SE 15

Dopo sei mesi di sviluppo, l'azienda Oracle ha rilasciato piattaforma Java SE 15 (Java Platform, Standard Edition 15), come implementazione di riferimento per il quale viene utilizzato il progetto open source OpenJDK. In Java SE 15 è mantenuta la compatibilità all'indietro con le versioni precedenti della piattaforma Java, tutti i progetti Java precedentemente scritti funzioneranno senza modifiche quando eseguiti con la nuova versione. Le versioni pronte per l'installazione di Java SE 15 (JDK, JRE e Server JRE) sono stati preparati per Linux (x86_64), Windows e macOS. L'implementazione di riferimento sviluppata nell'ambito del progetto OpenJDK Java 15 è completamente aperta sotto licenza GPLv2 con eccezioni GNU ClassPath, che consentono il binding dinamico con prodotti commerciali.

Java SE 15 è classificato come una versione con un normale ciclo di supporto, aggiornamenti per cui verranno rilasciati fino al prossimo rilascio. Si consiglia di utilizzare Java SE 11 come ramo a lungo termine (LTS), per il quale gli aggiornamenti verranno rilasciati fino al 2026. L'ultima versione LTS, Java 8, sarà supportata fino a dicembre 2020. Il prossimo rilascio LTS è previsto per settembre 2021. Ricordiamo che a partire dal rilascio di Java 10, il progetto è passato a un nuovo processo di sviluppo che prevede cicli di rilascio più brevi. La nuova funzionalità è ora sviluppata in un ramo master costantemente aggiornato, nel quale vengono inclusi già i cambiamenti pronti e da cui si diramano rami per la stabilizzazione delle nuove versioni ogni sei mesi.

Da novità Java 15 è possibile segnalare:

Incorporata supporto per l'algoritmo di creazione di firme digitali EdDSA (Edwards-Curve Digital Signature Algorithm RFC 8032). L'implementazione proposta di EdDSA non dipende dalle piattaforme hardware, è protetta da attacchi laterali (garantita la costanza nel tempo di tutti i calcoli) e supera in prestazioni l'implementazione esistente di ECDSA, scritta in linguaggio C, mantenendo lo stesso livello di sicurezza. Ad esempio, EdDSA utilizzando una curva ellittica con chiave a 126 bit mostra prestazioni simili a ECDSA con curva ellittica secp256r1 e chiave a 128 bit.
È stata aggiunta supporto sperimentale per classi e interfacce sigillate («sealed»), che non possono essere utilizzate da altre classi e interfacce per ereditarietà, estensione o overriding dell'implementazione. Le classi sigillate offrono anche un modo più dichiarativo di limitare l'uso del supertipo, rispetto ai modificatori di accesso, che si basa sulla enumerazione esplicita delle sottoclassi consentite 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 {…}
È stata aggiunta supporto per classi nascoste, che non possono essere utilizzate direttamente dal bytecode di altre classi. Lo scopo principale delle classi nascoste è l'uso in framework che generano dinamicamente classi durante l'esecuzione e le utilizzano in modo indiretto, tramite riflessione. Tali classi di solito hanno un ciclo di vita limitato, quindi mantenerle accessibili 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 essere rimossa in futuro.
Stabilito e riconosciuto come pronto per l'uso generalizzato il garbage collector ZGC (Z Garbage Collector). ZGC opera in modalità passiva e minimizza il più possibile i ritardi dovuti alla raccolta dei rifiuti (il tempo di arresto durante l'uso di ZGC non supera i 10 ms) e può lavorare sia con heap piccoli che enormi, dalle diverse centinaia di megabyte a molti terabyte.
Stabilito e riconosciuto come pronto per l'uso generalizzato
garbage collector Shenandoah, che lavora con pause minime (Low-Pause-Time Garbage Collector). Shenandoah è stato sviluppato da Red Hat ed è noto per l'uso di un algoritmo che riduce i tempi di arresto durante la raccolta dei rifiuti, effettuando la pulizia parallelamente all'esecuzione delle applicazioni Java. La dimensione dei ritardi causati dal garbage collector è prevedibile e non dipende dalle dimensioni dell'heap, quindi per heap da 200 MB e 200 GB i ritardi saranno identici (non superano i 50 ms e di solito si attestano attorno ai 10 ms);
Stabilita e introdotta nel linguaggio il supporto per blocchi di testo — una nuova forma di stringhe letterali, che consente di includere nel codice sorgente dati testuali multilinea senza richiedere l'escape dei caratteri e mantenendo la formattazione originale del testo nel blocco. L'incapsulamento del blocco avviene tramite tre virgolette doppie.
Ad esempio, invece del codice
String html = «<HTML>» +
«\n\t» + «<BODY>» +
"\n\t\t" + "
\"Java 15 is here!\"" +
«\n\t» + «<\/BODY>» +
«\n» + «<\/HTML>»;
si può specificare:
String html = «»»
<HTML>
<BODY>
"Java 15\
è arrivato!»<\/H1>
<\/BODY>
<\/HTML>»»»;
Ristrutturato API Legacy DatagramSocket. Le vecchie implementazioni di java.net.DatagramSocket e java.net.MulticastSocket sono state sostituite da un'implementazione moderna, più semplice da debug e manutenzione, e anche compatibile con flussi virtuali, sviluppati nell'ambito del progetto Loom. Nel caso di possibili problemi di compatibilità con il codice esistente, la vecchia implementazione non è stata rimossa e può essere attivata tramite l'opzione jdk.net.usePlainDatagramSocketImpl.
È stata proposta una seconda implementazione sperimentale corrispondenza con il modello 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 definire esplicitamente «String s = (String) obj».
Era:
if (obj instanceof Group) {
Group group = (Group) obj;
var entries = group.getEntries();
}
Ora è possibile omettere la definizione «Group group = (Group) obj»:
if (obj instanceof Group group) {
var entries = group.getEntries();
}
Proposta seconda implementazione sperimentale della parola chiave «record», che fornisce una forma compatta per definire classi, consentendo di evitare la 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 predefinite dei metodi equals(), hashCode() e toString(), è possibile evitare la loro definizione esplicita:
record pubblico BankTransaction(LocalDate data,
double importo,
String descrizione) {}
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).
Proposto seconda versione preliminare dell'API Foreign-Memory Access, che consente alle applicazioni Java di accedere in modo sicuro ed efficiente alle aree di memoria al di fuori dell'heap Java, manipolando le nuove astrazioni MemorySegment, MemoryAddress e MemoryLayout.
Disattivato ed è stata dichiarata obsoleta la tecnica di ottimizzazione Biased Locking, utilizzata nella JVM HotSpot per ridurre i costi di locking. Questa tecnica ha perso rilevanza nei sistemi con istruzioni atomiche fornite dai moderni CPU ed è troppo complessa per essere mantenuta.
Annunciato meccanismo obsoleto RMI Activation, che sarà rimosso in una delle prossime versioni. Si osserva che l'RMI Activation è obsoleto, è stato declassato a opzione già in Java 8 e viene raramente utilizzato nelle pratiche moderne.
Rimosso motore JavaScript Nashorn, che è stato dichiarato obsoleto in Java SE 11.
Rimossi porting per i sistemi operativi Solaris e processori SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). La rimozione di questi porti permetterà alla comunità di accelerare lo sviluppo di nuove funzionalità di OpenJDK, senza perdere tempo nella manutenzione di caratteristiche specifiche per Solaris e SPARC.