🥇Rilascio di Java SE 24 e OpenJDK 24

Dopo sei mesi di sviluppo, Oracle ha pubblicato la piattaforma Java SE 24 (Java Platform, Standard Edition 24), utilizzando il progetto open source OpenJDK come implementazione di riferimento. Fatta eccezione per la rimozione di alcune funzionalità obsolette, Java SE 24 mantiene la compatibilità retroattiva con le versioni precedenti della piattaforma Java: la maggior parte dei progetti Java già scritti funzionerà senza modifiche con la nuova versione. Le build pronte per l'installazione di Java SE 24 (JDK, JRE e Server JRE) sono state preparate per Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). L'implementazione di riferimento di Java SE 24, sviluppata nell'ambito del progetto OpenJDK, è completamente open source sotto la licenza GPLv2 con eccezioni GNU ClassPath, che consentono il legame dinamico con prodotti commerciali.

Java SE 24 è classificato come una release con un normale ciclo di supporto, con aggiornamenti rilasciati fino alla prossima versione. Per un ramo con supporto a lungo termine (LTS), si consiglia di utilizzare Java SE 21 o Java SE 17, gli aggiornamenti dei quali saranno rilasciati rispettivamente fino al 2031 e al 2029 (disponibili pubblicamente fino al 2028 e al 2026). Il supporto esteso per il ramo LTS di Java SE 8 continuerà fino al 2030, mentre Java SE 11 durerà fino al 2032. La prossima release LTS sarà l'uscita autunnale di Java SE 25.

Tra le novità proposte in Java SE 24:

È stata proposta una modalità generativa sperimentale per il garbage collector Shenandoah, in cui gli oggetti vecchi e quelli appena creati vengono trattati separatamente per migliorare l'efficienza nella pulizia degli oggetti con una breve durata. La nuova modalità garantisce una capacità di elaborazione più prevedibile, resilienza ai cambiamenti di carico e una riduzione dell'uso della memoria durante la raccolta dei rifiuti. Il pianificatore Shenandoah mira a ridurre il tempo di arresto durante la raccolta dei rifiuti eseguendo una maggiore quantità di lavoro in parallelo con l'esecuzione delle applicazioni Java.
È stata implementata nel HotSpot JVM un supporto sperimentale per intestazioni compatte degli oggetti, il cui size è stato ridotto da 96 a 64 bit (da 12 a 8 byte) sui sistemi a 64 bit. La riduzione delle dimensioni delle intestazioni consente di ridurre la dimensione dell'heap e migliorare l'efficienza del lavoro della cache.
Nel raccoglitore di spazzatura G1, è stata semplificata l'implementazione delle barriere che monitorano l'accesso dell'applicazione alla memoria. Nella nuova versione, le operazioni di estensione delle barriere sono state spostate in una fase successiva della compilazione nel C2 JIT. I test condotti mostrano che tale spostamento consente di ridurre i costi indiretti nel compilatore JIT C2 dal 10 al 20%, a seconda dell'applicazione.
È stata aggiunta un'API per l'utilizzo delle funzioni crittografiche di derivazione delle chiavi (KDF, key derivation function), che consentono di generare ulteriori chiavi di lunghezza necessaria sulla base di una chiave segreta (ad esempio, una password) e di un insieme arbitrario di dati. L'API KDF ha attualmente lo status di anteprima.
È stata aggiunta la possibilità di caricamento e collegamento anticipato (Ahead-of-Time) delle classi. Questa modifica accelera l'avvio della HotSpot JVM fornendo le classi utilizzate nell'applicazione in uno stato già caricato e collegato. Durante il primo avvio dell'applicazione, lo stato di tutte le classi viene memorizzato nella cache e utilizzato per velocizzare il caricamento nei successivi avvii.
È stata aggiunta un'API Class-File per l'analisi, la generazione e la conversione dei file delle classi Java.
ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith(«debug»))) { classBuilder.with(ce); } } });
È stata aggiunta un'API Stream estesa, che supporta la definizione di operazioni intermedie personalizzate, utili nei casi in cui le operazioni intermedie incorporate non siano sufficienti per la trasformazione dei dati desiderata. I gestori personalizzati vengono collegati tramite la nuova operazione intermedia Stream::gather(Gatherer), che elabora gli elementi dello stream applicando loro un gestore fornito dall'utente. jshell> Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
È stata proposta una quarta implementazione preliminare dei valori limitati (Scoped Values), che consentono la condivisione di dati immutabili nei thread e lo scambio efficiente di dati tra thread secondari (i valori sono ereditati). Gli Scoped Values vengono sviluppati per sostituire il meccanismo delle variabili locali nel thread (thread-local variables) e sono più efficienti quando si utilizzano un numero molto elevato di thread virtuali (migliaia o milioni di thread). La principale differenza tra Scoped Values e le variabili locali nel thread è che i primi vengono scritti una sola volta, non possono essere successivamente modificati e restano accessibili solo durante l'esecuzione del thread.
Nella meccanica di corrispondenza con il modello è stato aggiunto il supporto preliminare per l'uso dei tipi primitivi (int, byte, char e altri tipi di base che non sono oggetti) in tutti i tipi di template, nell'operatore «instanceof» e nei blocchi «switch». switch (x.getStatus()) { case 0 -> «okay»; case 1 -> «warning»; case 2 -> «error»; case int i -> «unknown status: » + i; } if (i instanceof byte b) { … b … }
È stata proposta una nona implementazione preliminare dell'API Vector, che fornisce funzioni per calcoli vettoriali eseguiti utilizzando le istruzioni vettoriali dei processori x86_64 e AArch64, consentendo di applicare operazioni a più valori contemporaneamente (SIMD). A differenza delle capacità di auto-vettorizzazione delle operazioni scalari fornite dal compilatore JIT HotSpot, la nuova API offre la possibilità di gestire esplicitamente la vettorizzazione per l'elaborazione parallela dei dati.
È stato implementato il supporto per la sincronizzazione dei thread virtuali senza il loro collegamento (pinning) ai thread legati alla piattaforma. I thread virtuali in un metodo o espressione sincronizzata in stato di blocco ora liberano il loro thread di piattaforma, consentendo ad altri thread virtuali di utilizzarlo, aumentando notevolmente il numero di thread virtuali disponibili e migliorando la scalabilità delle applicazioni che utilizzano il multithreading.
È stata aggiunta una terza versione preliminare della funzionalità che consente di specificare nei costruttori di espressioni prima della chiamata a super(…), utilizzata per invocare esplicitamente il costruttore della classe genitore dal costruttore della classe ereditata, se queste espressioni non fanno riferimento all'istanza creata dal costruttore. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
La utility jlink ha implementato il supporto per la creazione di immagini di runtime senza l'uso di file JMOD, il che consente di ridurre la dimensione del JDK di circa il 25%.
È stata aggiunta una seconda versione preliminare per utilizzare un'unica espressione "import module M" per importare immediatamente tutti i pacchetti esportati dal modulo specificato. Questa modifica semplifica notevolmente il riutilizzo delle librerie modulari, consentendo di collegare librerie e classi senza dover definire la loro posizione gerarchica. Ad esempio, specificare "import module java.base" porterà all'importazione di tutti i 54 pacchetti contenuti nel modulo java.base, che in precedenza avrebbero dovuto essere menzionati singolarmente ("import java.io.*", "import java.util.*" ecc.).
È stata aggiunta una quarta implementazione preliminare per le classi dichiarate implicitamente e le istanze anonime del metodo "main", in cui è possibile fare a meno delle dichiarazioni public/static, della trasmissione di un array di argomenti e di altre entità correlate alla dichiarazione della classe. // prima public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // adesso è possibile void main() { System.out.println("Hello, World!"); }
È stata proposta per il test una quarta versione preliminare dell'API per la concorrenza strutturata (Structured Concurrency), che semplifica lo sviluppo di applicazioni multithreading gestendo più attività eseguite in thread diversi come un'unica unità.
Nell'API KeyPairGenerator, Signature e KeyFactory è stato aggiunto il supporto per gli algoritmi ML-KEM (CRYSTALS-Kyber) e ML-DSA (CRYSTALS-Dilithium), standardizzati dall'Istituto nazionale degli standard e della tecnologia degli Stati Uniti (NIST) e resistenti agli attacchi di un computer quantistico. Questi algoritmi utilizzano metodi crittografici basati sulla risoluzione di problemi della teoria dei reticoli, il cui tempo di risoluzione non differisce tra computer classici e quantistici.
Nel garbage collector ZGC è stata rimossa la supporto alla modalità non generativa, che non separa il trattamento degli oggetti "vecchi" e "giovani". A partire da Java SE 23, la modalità generativa di ZGC è applicata per impostazione predefinita.
È stata aggiunta la segnalazione di avvisi sull'uso delle API JNI (Java Native Interface) e FFM (Foreign Function & Memory) per preparare gli sviluppatori a una limitazione dell'accesso ai dati di queste API a causa dell'introduzione in una delle future versioni di una modalità di protezione dell'integrità, che per impostazione predefinita vieta l'interazione con il codice nativo.
È stata attivata la segnalazione di avvisi quando si utilizzano i metodi di accesso alla memoria esterna (fuori dalla JVM) forniti dalla classe sun.misc.Unsafe. Per accedere alla memoria al di fuori dell'heap e interagire con codici esterni, si consiglia di utilizzare l'API VarHandle. Nella versione precedente, il supporto per sun.misc.Unsafe è stato dichiarato obsoleto.
Il Security Manager, che ha perso rilevanza e non è più richiesto dopo l'interruzione del supporto per il plugin del browser, è stato disabilitato. Il Security Manager è stato dichiarato obsoleto in Java 17. È previsto che in una delle prossime versioni il codice del Security Manager venga completamente rimosso.
È stato rimosso il codice per il supporto della piattaforma a 32 bit del sistema operativo Windows su sistemi x86. Il port per sistemi x86 a 32 bit è stato dichiarato obsoleto e programmato per la rimozione (il supporto per Linux su sistemi a 32 bit x86 sarà interrotto).

È possibile notare la pubblicazione dell'aggiornamento della piattaforma per la creazione di applicazioni con interfaccia grafica JavaFX 24 e una nuova versione della macchina virtuale universale GraalVM, che supporta l'esecuzione di applicazioni in JavaScript (Node.js), Python, Ruby, R, e in qualsiasi linguaggio per JVM (Java, Scala, Clojure, Kotlin) e nei linguaggi per i quali può essere generato bytecode LLVM (C, C++, Rust). Oltre al supporto per JDK 24, nella nuova versione di GraalVM sono state effettuate ottimizzazioni per compiti legati all'apprendimento automatico, migliorato il supporto per la compilazione del bytecode Java in codice macchina, e aggiunto un meccanismo SkipFlow per ridurre la dimensione dei file eseguibili e il tempo di compilazione.

Fonte: opennet.ru