{"id":143670,"date":"2025-09-17T11:12:01","date_gmt":"2025-09-17T09:12:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-25-lts-i-openjdk-25"},"modified":"2025-09-17T11:12:01","modified_gmt":"2025-09-17T09:12:01","slug":"vypusk-java-se-25-lts-i-openjdk-25","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-java-se-25-lts-i-openjdk-25","title":{"rendered":"Ufficiale la versione Java SE 25 LTS e OpenJDK 25","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo sei mesi di sviluppo, Oracle ha rilasciato la piattaforma Java SE 25 (Java Platform, Standard Edition 24), la cui implementazione di riferimento si basa sul progetto open source OpenJDK. A parte la rimozione di alcune funzionalit\u00e0 obsolete, Java SE 25 mantiene la retrocompatibilit\u00e0 con le versioni precedenti della piattaforma Java: la maggior parte dei progetti Java precedentemente scritti funzioner\u00e0 senza modifiche con la nuova versione. Le versioni pronte per l'installazione di Java SE 25 (JDK, JRE e Server JRE) sono disponibili per Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). L'implementazione di riferimento di Java SE 25, sviluppata nell'ambito del progetto OpenJDK, \u00e8 completamente open source con licenza GPLv2 con eccezioni GNU ClassPath, che consentono il collegamento dinamico a prodotti commerciali. <\/p>\n
Java SE 25 \u00e8 classificato come una release con supporto a lungo termine, con aggiornamenti previsti fino al 2033 (gli aggiornamenti pubblici saranno disponibili fino a settembre 2030). Le versioni Java SE 17 e 21 continuano ad essere supportate come release LTS, con aggiornamenti previsti rispettivamente fino al 2029 e 2031 (aggiornamenti pubblici - fino al 2026 e 2028). Il supporto esteso per le release LTS di Java SE 8 e 11 durer\u00e0 fino al 2030 e 2032. <\/p>\n
Tra le novit\u00e0 proposte in Java SE 25 (1, 2, 3, 4): <\/p>\n
\n
\u00c8 stato aggiunto un API sperimentale StableValue per lavorare con oggetti contenenti dati immutabili e gestiti nella JVM come costanti. A questi oggetti vengono applicate ottimizzazioni delle prestazioni simili ai campi contrassegnati con la parola chiave \u00abfinal\u00bb. L'API StableValue separa la creazione di valori costanti dalla loro inizializzazione, garantendo che un valore possa essere inizializzato solo una volta, riducendo il tempo di avvio delle applicazioni e consentendo di applicare nel codice utente ottimizzazioni di folding delle costanti (constant-folding), utilizzate in precedenza solo nel codice interno del JDK. class Application { \/\/ Prima: \/\/ static final UserService USERS = new UserService(); \/\/ Dopo: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
\u00c8 stato aggiunto un API sperimentale per la codifica e la decodifica di oggetti contenenti chiavi crittografiche, certificati e liste di certificati revocati, utilizzando il formato PEM (Pivacy-Enhanced Mail).\n
\u00c8 stata aggiunta la supporto ai Scoped Values, che consentono di condividere dati immutabili nei thread e di scambiare dati in modo efficiente tra i thread figlio (i valori vengono ereditati). Gli Scoped Values sono in fase di sviluppo per sostituire il meccanismo delle variabili locali al thread e sono pi\u00f9 efficienti quando si utilizzano un numero molto elevato di thread virtuali (migliaia e milioni di thread). La principale differenza tra Scoped Values e le variabili locali al thread \u00e8 che i primi vengono scritti una volta, non possono essere modificati ulteriormente e sono accessibili solo durante l'esecuzione del thread.\n
\u00c8 stata aggiunta un'API per l'uso di funzioni crittografiche per la derivazione delle chiavi (KDF, key derivation function), che consentono di generare chiavi aggiuntive della lunghezza necessaria a partire da una chiave segreta (ad esempio, una password) e da un insieme di dati arbitrari.\n
\u00c8 stato rimosso il codice e gli script di build per il supporto dei sistemi x86 a 32 bit. La cessazione del supporto per i sistemi x86 a 32 bit ha semplificato l'infrastruttura per la build e i test del JDK e ha reso possibile implementare funzionalit\u00e0 legate alle piattaforme senza creare gestori di fallback per i sistemi a 32 bit.\n
\u00c8 stata aggiunta la possibilit\u00e0 di utilizzare un'unica espressione \u00abimport module M\u00bb per importare tutti i pacchetti esportati dal modulo specificato. Questa modifica semplifica notevolmente il riutilizzo delle librerie modulari, consentendo di collegare librerie e classi senza definire la loro posizione nella gerarchia dei pacchetti. Ad esempio, specificando \u00abimport module java.base\u00bb si importeranno tutti i 54 pacchetti che fanno parte del modulo java.base, che in precedenza avrebbero dovuto essere menzionati singolarmente (\u00abimport java.io.*\u00bb, \u00abimport java.util.*\u00bb, ecc.).\n
\u00c8 stata proposta una versione compatta per la strutturazione dei programmi, che potrebbe risultare utile per l'insegnamento e per lo sviluppo di piccole applicazioni. In forma compatta non \u00e8 necessario definire classi superflue, gli API comuni vengono importati automaticamente e i metodi semplificati di input\/output sono disponibili. Ad esempio, l'applicazione \u00abHello, World!\u00bb pu\u00f2 essere ridotta a: void main() { IO.println(\u00abHello, World!\u00bb); }\n
\u00c8 ora consentito specificare espressioni nei costruttori prima della chiamata a super(...), utilizzata per chiamare esplicitamente il costruttore della classe genitore dal costruttore della classe derivata, a condizione che queste espressioni non facciano riferimento all'istanza creata dal costruttore. class Outer { void hello() { System.out.println(\u00abHello\u00bb); } class Inner { Inner() { hello(); super(); } } }\n
\u00c8 stata aggiunta la modalit\u00e0 generativa per il garbage collector Shenandoah, in cui gli oggetti vecchi e quelli appena creati vengono elaborati separatamente per migliorare l'efficienza della pulizia degli oggetti con breve vita. La nuova modalit\u00e0 garantisce una larghezza di banda pi\u00f9 prevedibile, maggiore resilienza alle variazioni di carico e una riduzione dell'uso della memoria durante la raccolta dei rifiuti. Lo scheduler di Shenandoah \u00e8 progettato per ridurre i tempi di arresto durante la raccolta dei rifiuti effettuando un maggior volume di lavoro in parallelo con l'esecuzione di applicazioni Java.\n
\u00c8 stato semplificato il processo di creazione della cache per il caricamento e la compilazione anticipati (Ahead-of-Time) delle classi, che consente di accelerare l'avvio della HotSpot JVM sfruttando classi gi\u00e0 caricate e compilate. All'avvio non sono pi\u00f9 necessarie operazioni separate per la registrazione delle attivit\u00e0 e la creazione della cache, basta un solo comando: java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App ...\n
All'avvio della HotSpot Java VM \u00e8 stata implementata la possibilit\u00e0 di utilizzare profili di esecuzione dei metodi ottenuti durante l'ultima esecuzione dell'applicazione. Questa modifica consente al compilatore JIT di fare a meno della raccolta di statistiche e di iniziare immediatamente a generare codice nativo senza attendere la formazione del profilo.\n
Nella HotSpot JVM \u00e8 stata implementata la supporto per intestazioni compatte degli oggetti, il cui size sui sistemi a 64 bit \u00e8 stato ridotto da 96 a 64 bit (da 12 a 8 byte). La riduzione delle dimensioni delle intestazioni permette di ridurre la dimensione dell'heap e di migliorare l'efficienza del cache.\n
\u00c8 stata proposta un'implementazione di prova dell'API Vector, che offre funzioni per calcoli vettoriali eseguiti utilizzando le istruzioni vettoriali dei processori x86_64 e AArch64, consentendo di applicare contemporaneamente operazioni a pi\u00f9 valori (SIMD). A differenza delle capacit\u00e0 di auto-vettorizzazione delle operazioni scalari fornite dal compilatore JIT HotSpot, la nuova API consente un controllo esplicito sulla vettorizzazione per l'elaborazione parallela dei dati.\n
\u00c8 stato proposto per la sperimentazione un quinto preliminare dell'API per la concorrenza strutturata (Structured Concurrency), che semplifica lo sviluppo di applicazioni multi-thread gestendo pi\u00f9 attivit\u00e0 eseguite in thread diversi come un'unica unit\u00e0.\n
Nell meccanismo di corrispondenza dei pattern \u00e8 stata proposta una terza opzione preliminare per l'uso dei tipi primitivi (int, byte, char e altri tipi di base che non sono oggetti) in tutti i tipi di modelli, nell'operatore \u00abinstanceof\u00bb e nei blocchi \u00abswitch\u00bb. switch (x.getStatus()) { case 0 -> \u00abokay\u00bb; case 1 -> \u00abwarning\u00bb; case 2 -> \u00aberror\u00bb; case int i -> \u00abunknown status: \u00bb + i; } if (i instanceof byte b) { ... b ... }\n
Nel JDK Flight Recorder (JFR) \u00e8 stata aggiunta un'apposita supporto sperimentale per il profiling con un tracciamento pi\u00f9 preciso dell'uso delle risorse CPU sulla piattaforma Linux. Le informazioni sui tempi di esecuzione di varie costruzioni possono essere visualizzate chiaramente utilizzando grafici colorati «FlameGraph».\n
\u00c8 stata aumentata la stabilit\u00e0 del funzionamento del JDK Flight Recorder (JFR) durante il campionamento asincrono degli stack dei thread Java, grazie all'attraversamento dello stack dei chiamate solo nei «punti sicuri» (safepoints).\n
Nel JDK Flight Recorder (JFR) sono stati aggiunti strumenti di tracciamento e valutazione del tempo di esecuzione dei metodi. \u00c8 supportato il tracciamento dello stack delle chiamate di specifici metodi e la registrazione di statistiche dettagliate sulle chiamate ai metodi, che includono metriche come il tempo di esecuzione e il numero di chiamate. <\/ul>\n