JDK 15: le nuove funzionalità di Java 15

Java Development Kit 15, l'implementazione Oracle della prossima versione di Java SE (Standard Edition), diventa disponibile come rilascio di produzione oggi, 15 settembre 2020. I punti salienti di JDK 15 includono blocchi di testo, classi nascoste, un'API di accesso alla memoria esterna, Z Garbage Collector e anteprime di classi sigillate, corrispondenza di modelli e record.

JDK 15 è solo una versione a breve termine, che verrà supportata solo con Oracle Premier Support per sei mesi fino all'arrivo di JDK 16 il prossimo marzo. JDK 17, la prossima versione del supporto a lungo termine, che sarà supportata da Oracle per otto anni, dovrebbe arrivare tra un anno, secondo la cadenza di rilascio di sei mesi di Oracle per le versioni di Java SE.

Gli sviluppatori possono guardare JDK 15 ora per avere un'idea di ciò che sarà in JDK 17, ha affermato Georges Saab, presidente del Java Platform Group di Oracle. L'attuale versione di LTS è JDK 11, arrivata a settembre 2018. Le versioni di LTS arrivano ogni tre anni. JDK 15 segue JDK 14, pubblicato il 17 marzo 2020. 

Le nuove funzionalità e modifiche in OpenJDK 15:

  • Un secondo incubatore di un'API di accesso alla memoria esterna, che consentirebbe ai programmi Java di accedere in modo sicuro ed efficiente alla memoria esterna al di fuori dell'heap Java. L'API dovrebbe essere in grado di operare su vari tipi di memoria esterna, come heap nativo, persistente e gestito. Molti programmi Java accedono alla memoria esterna, come Ignite e MapDB. L'API aiuterebbe a evitare i costi e l'imprevedibilità associati alla raccolta dei rifiuti, condividere la memoria tra i processi e serializzare e deserializzare il contenuto della memoria mappando i file sulla memoria. L'API Java attualmente non fornisce una soluzione soddisfacente per l'accesso alla memoria esterna. Ma con la nuova proposta, non dovrebbe essere possibile per l'API minare la sicurezza della JVM. Questa capacità sta attraversando una fase precedente dell'incubatore in JDK 14, con perfezionamenti offerti in JDK 15. 
  • Un'anteprima delle classi sigillate. Insieme alle interfacce, le classi sigillate limitano le altre classi o interfacce che possono estenderle o implementarle. Gli obiettivi di questa funzionalità includono consentire all'autore di una classe o di un'interfaccia di controllare quale codice è responsabile dell'implementazione, fornire un modo più dichiarativo rispetto ai modificatori di accesso per limitare l'uso di una superclasse e supportare le direzioni future nel pattern matching sostenendo l'esaustivo analisi dei modelli.
  • Rimozione del codice sorgente e supporto della build per le porte Solaris / SPARC, Solaris / x64 e Linux / SPARC, che erano state ritirate per la rimozione in JDK 14 con l'intento di rimuoverle in una versione futura. Molti progetti e funzionalità in fase di sviluppo come Valhalla, Loom e Panama richiedono modifiche significative all'architettura della CPU e al codice specifico del sistema operativo. L'abbandono del supporto per le porte Solaris e SPARC consentirà ai collaboratori della comunità OpenJDK di accelerare lo sviluppo di nuove funzionalità che faranno avanzare la piattaforma. Sia Solaris che SPARC sono stati sostituiti negli ultimi anni dal sistema operativo Linux e dai processori Intel.
  • I record, che sono classi che fungono da vettori trasparenti per dati immutabili, sarebbero inclusi in una seconda versione di anteprima in JDK 15, dopo aver debuttato come anteprima in JDK 14. Gli obiettivi del piano includono l'ideazione di un costrutto orientato agli oggetti che esprima un semplice aggregazione di valori, aiutando i programmatori a concentrarsi sulla modellazione di dati immutabili piuttosto che su comportamenti estensibili, implementando automaticamente metodi basati sui dati come uguali e valutatori e preservando principi Java di vecchia data come la tipizzazione nominale e la compatibilità della migrazione. I record possono essere considerati come tuple nominali. 
  • Firme crittografiche basate su Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA è un moderno schema a curva ellittica con vantaggi rispetto agli schemi di firma esistenti nel JDK. EdDSA verrà implementato solo nel provider SunEC. EdDSA è richiesto a causa della sua maggiore sicurezza e prestazioni rispetto ad altri schemi di firma; è già supportato nelle librerie crittografiche come OpenSSL e BoringSSL.
  • Reimplementazione dell'API DatagramSocket legacy sostituendo le implementazioni sottostanti delle  API java.net.datagram.Sockete java.net.MulticastSocketcon implementazioni più semplici e moderne che 1. sono facili da eseguire il debug e mantenere e 2. funzionano con i thread virtuali attualmente esplorati in Project Loom. Il nuovo piano è un seguito alla proposta di miglioramento JDK 353 che ha reimplementato l'API Socket legacy. Le attuali implementazioni di java.net.datagram.Sockete java.net.MulticastSocketrisalgono a JDK 1.0 e al tempo in cui IPv6 era ancora in fase di sviluppo. Pertanto, l'attuale implementazione di  MulticastSocket cerca di riconciliare IPv4 e IPv6 in modi difficili da mantenere.
  • Disabilitazione del blocco parziale per impostazione predefinita e deprecazione di tutte le opzioni della riga di comando correlate. L'obiettivo è determinare la necessità di un supporto continuo per l'ottimizzazione della sincronizzazione legacy costosa da mantenere del blocco parziale, che viene utilizzato nella macchina virtuale HotSpot per ridurre il sovraccarico del blocco incontrollato. Sebbene alcune applicazioni Java possano vedere una regressione delle prestazioni con il blocco polarizzato disabilitato, i guadagni in termini di prestazioni del blocco polarizzato sono generalmente meno evidenti di quanto non lo fossero in passato.
  • Una seconda anteprima del pattern matching per instanceof, che segue un'anteprima precedente in JDK 14. Il pattern matching consente di esprimere più facilmente e in modo conciso la logica comune in un programma, principalmente l'estrazione condizionale dei componenti dagli oggetti. Linguaggi come Haskell e C # hanno adottato la corrispondenza dei modelli per la sua brevità e sicurezza.
  • Le classi nascoste, ovvero le classi che non possono essere utilizzate direttamente dal bytecode di altre classi, sono destinate all'uso da parte di framework che generano classi in fase di esecuzione e che le utilizzano indirettamente tramite la reflection. Una classe nascosta può essere definita come un membro di un nido di controllo di accesso e può essere scaricata indipendentemente dalle altre classi. La proposta migliorerebbe l'efficienza di tutte le lingue sulla JVM consentendo a un'API standard di definire classi nascoste che non sono rilevabili e hanno un ciclo di vita limitato. I framework all'interno e all'esterno del JDK sarebbero in grado di generare dinamicamente classi che potrebbero invece definire classi nascoste. Molti linguaggi basati sulla JVM si basano sulla generazione di classi dinamiche per flessibilità ed efficienza. Gli obiettivi di questa proposta includono: consentire ai framework di definire le classi come dettagli di implementazione non rilevabili del framework,quindi non possono essere collegati con altre classi né scoperti attraverso la riflessione; supporto per l'estensione di un nido di controllo degli accessi con classi non rilevabili; e supporto per lo scaricamento aggressivo di classi non rilevabili, in modo che i framework abbiano la flessibilità di definirne quante ne sono necessarie. Un altro obiettivo è deprecare l'API non standard, misc.Unsafe::defineAnonymousClass, con l'intento di deprecare per la rimozione in una versione futura. Inoltre, il linguaggio Java non deve essere modificato a seguito di questa proposta.
  • Lo Z Garbage Collector (ZGC) passa da una funzionalità sperimentale a un prodotto nell'ambito di questa proposta. Integrato in JDK 11, disponibile a settembre 2018, ZGC è un garbage collector scalabile a bassa latenza. ZGC è stato introdotto come capacità sperimentale perché gli sviluppatori di Java hanno deciso che una caratteristica di queste dimensioni e complessità dovrebbe essere introdotta con attenzione e gradualmente. Da allora, sono stati aggiunti numerosi miglioramenti, che vanno dallo scaricamento simultaneo della classe, dalla mancata trasmissione della memoria inutilizzata e dal supporto per la condivisione dei dati di classe, al miglioramento della consapevolezza NUMA e al pre-tocco dell'heap multi-thread. Inoltre, la dimensione massima dell'heap è stata aumentata da quattro terabyte a 16 terabyte. ZGC risolve i problemi di prestazioni nelle applicazioni che coinvolgono enormi quantità di dati, come l'apprendimento automatico,dove gli utenti vogliono essere sicuri che il trattamento dei dati non sarà soggetto a imprevedibilità o lunghe pause a causa della raccolta dei rifiuti. Le piattaforme supportate includono Linux, Windows e MacOS.
  • I blocchi di testo, visualizzati in anteprima sia in JDK 14 che in JDK 13, hanno lo scopo di semplificare il compito di scrivere programmi Java rendendo facile esprimere stringhe che si estendono su più righe di codice sorgente, evitando sequenze di escape nei casi comuni. Un blocco di testo è una stringa letterale su più righe che evita la necessità della maggior parte delle sequenze di escape, formatta automaticamente la stringa in modo prevedibile e offre allo sviluppatore il controllo sul formato quando desiderato. Uno degli obiettivi della proposta di blocchi di testo è migliorare la leggibilità delle stringhe nei programmi Java che denotano codice scritto in linguaggi non Java. Un altro obiettivo è supportare la migrazione da stringhe letterali stabilendo che qualsiasi nuovo costrutto possa esprimere lo stesso insieme di stringhe come stringa letterale, interpretare le stesse sequenze di escape ed essere manipolato allo stesso modo di una stringa letterale.Gli sviluppatori di OpenJDK sperano di aggiungere sequenze di escape per gestire lo spazio bianco esplicito e il controllo di nuova riga.
  • Il netturbino Shenandoah a bassa pausa sarebbe diventato un elemento di produzione e sarebbe uscito dalla fase sperimentale. Era stato integrato in JDK 12 un anno fa.
  • Rimozione di Nashorn, che ha debuttato in JDK 8 a marzo 2014, ma da allora è stata resa obsoleta da tecnologie come GraalVM. La proposta di OpenJDK 15 richiede la rimozione delle API Nashorn e lo strumento della riga di comando jjs utilizzato per richiamare Nashorn.
  • Deprecazione del meccanismo di attivazione RMI, per futura rimozione. Il meccanismo di attivazione RMI è una parte obsoleta di RMI che è stata facoltativa da Java 8. L'attivazione RMI impone un onere di manutenzione continua. Nessun'altra parte di RMI sarà deprecata.