{"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\/novosti-interneta\/vypusk-java-se-25-lts-i-openjdk-25","title":{"rendered":"Rilascio di Java SE 25 LTS e OpenJDK 25","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo sei mesi di sviluppo, Oracle ha pubblicato la piattaforma Java SE 25 (Java Platform, Standard Edition 24), per la quale viene utilizzato come implementazione di riferimento il progetto open source OpenJDK. Fatta eccezione per l'eliminazione 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 scritti in precedenza funzioneranno senza modifiche con la nuova versione. Le distribuzioni 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 aperta con licenza GPLv2 con eccezioni GNU ClassPath che consentono il collegamento dinamico con prodotti commerciali. <\/p>\n
Java SE 25 \u00e8 classificato come una versione con supporto a lungo termine, con aggiornamenti che saranno rilasciati fino al 2033 (gli aggiornamenti pubblici saranno distribuiti fino a settembre 2030). Anche le versioni Java SE 17 e 21 continuano a ricevere supporto come ramificazioni LTS, con aggiornamenti previsti fino al 2029 e 2031, rispettivamente (aggiornamenti pubblici fino al 2026 e 2028). Il supporto esteso per le ramificazioni LTS di Java SE 8 e 11 continuer\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 stata aggiunta un'API sperimentale StableValue per lavorare con oggetti contenenti dati immutabili e trattati nel JVM come costanti. Questi oggetti ricevono ottimizzazioni delle prestazioni simili ai campi contrassegnati con la parola chiave 'final'. L'API StableValue separa la creazione di valori costanti dalla loro inizializzazione, garantendo che il valore possa essere inizializzato solo una volta, riducendo il tempo di avvio delle applicazioni e consentendo di applicare ottimizzazioni di costante folding nel codice utente, in precedenza utilizzate solo nel codice interno del JDK. class Application { \/\/ Era: \/\/ static final UserService USERS = new UserService(); \/\/ \u00c8 diventato: 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 decodifica di oggetti contenenti chiavi crittografiche, certificati e elenchi di certificati revocati, utilizzando il formato PEM (Privacy-Enhanced Mail).\n
\u00c8 stato aggiunto il supporto per i valori scope (Scoped Values), che consentono di condividere dati immutabili nei flussi e di scambiare dati in modo efficiente tra flussi secondari (i valori sono ereditati). I Scoped Values si stanno sviluppando per sostituire il meccanismo delle variabili locali al flusso (thread-local variables) e sono pi\u00f9 efficienti quando si utilizzano un numero molto elevato di flussi virtuali (migliaia e milioni di flussi). La principale differenza tra i Scoped Values e le variabili locali al flusso \u00e8 che i primi vengono scritti una sola volta, non possono essere modificati ed rimangono disponibili solo durante l'esecuzione del flusso.\n
\u00c8 stata aggiunta un'API per utilizzare funzioni crittografiche di derivazione delle chiavi (KDF, key derivation function), che consentono di generare ulteriori chiavi di lunghezza necessaria a partire da una chiave segreta (ad esempio, una password) e da un insieme di dati arbitrario.\n
Il codice e gli script di build per supportare i sistemi a 32 bit x86 sono stati rimossi. La cessazione del supporto per i sistemi x86 a 32 bit ha semplificato l'infrastruttura per la costruzione e il test di JDK, e ha anche reso possibile implementare funzionalit\u00e0 legate a piattaforme senza dover creare gestori di fallback per i sistemi a 32 bit x86.\n
\u00c8 stata aggiunta la possibilit\u00e0 di utilizzare un'unica espressione 'import module M' 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 dover definire la loro posizione nella gerarchia dei pacchetti. Ad esempio, specificando 'import module java.base' si importeranno tutti i 54 pacchetti contenuti nel modulo java.base, che in precedenza avrebbero dovuto essere menzionati singolarmente ('import java.io.*', 'import java.util.*', ecc.).\n
\u00c8 stata proposta una variante compatta della scrittura dei programmi, utile per l'insegnamento e per lo sviluppo di piccole applicazioni. In forma compatta non \u00e8 necessario definire classi superflue, vengono automaticamente importati API di base e sono disponibili metodi semplificati di input\/output. Ad esempio, l'applicazione 'Hello, World!' pu\u00f2 essere ridotta a: void main() { IO.println('Hello, World!'); }\n
\u00c8 consentita la specifica di espressioni nei costruttori prima di chiamare super(...), utilizzato per chiamare esplicitamente il costruttore della classe genitore da un costruttore della classe derivata, a condizione che queste espressioni non facciano riferimento all'istanza dell'oggetto creata dal costruttore. class Outer { void hello() { System.out.println('Hello'); } class Inner { Inner() { hello(); super(); } } }\n
\u00c8 stata aggiunta una modalit\u00e0 generativa per il garbage collector Shenandoah, che gestisce separatamente gli oggetti vecchi e quelli appena creati per migliorare l'efficienza della pulizia degli oggetti a breve termine. Questa nuova modalit\u00e0 offre una capacit\u00e0 di elaborazione pi\u00f9 prevedibile, una maggiore resilienza alle variazioni di carico e una riduzione del consumo di memoria durante la raccolta dei rifiuti. Il pianificatore di Shenandoah mira a ridurre i tempi di arresto durante la raccolta dei rifiuti eseguendo un volume maggiore di lavoro in parallelo con l'esecuzione delle applicazioni Java.\n
\u00c8 stato semplificato il processo di creazione di una cache per il caricamento e l'assemblaggio anticipato (Ahead-of-Time) delle classi, che consente di accelerare l'avvio della HotSpot JVM coinvolgendo classi gi\u00e0 caricate e assemblate. Al momento dell'esecuzione non sono pi\u00f9 necessarie operazioni separate per registrare l'attivit\u00e0 e creare la cache, \u00e8 sufficiente un solo comando: java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App ...\n
All'avvio, HotSpot Java VM consente l'uso dei profili di esecuzione dei metodi ottenuti durante l'ultima esecuzione dell'applicazione. Questa modifica consente al JIT compiler di evitare la raccolta di statistiche e di iniziare immediatamente a generare codice nativo senza attendere la formazione del profilo.\n
HotSpot JVM supporta intestazioni degli oggetti compatte, la cui dimensione \u00e8 stata ridotta da 96 a 64 bit (da 12 a 8 byte) nei sistemi a 64 bit. La riduzione delle dimensioni delle intestazioni consente di ridurre la dimensione dell'heap e di aumentare l'efficienza della cache.\n
\u00c8 stata proposta un'implementazione di prova dell'API Vector, che fornisce funzioni per calcoli vettoriali eseguiti utilizzando le istruzioni vettoriali dei processori x86_64 e AArch64, permettendo di applicare operazioni contemporaneamente a pi\u00f9 valori (SIMD). A differenza delle capacit\u00e0 di auto-vettorizzazione delle operazioni scalari fornite dal JIT compiler di HotSpot, la nuova API consente di gestire esplicitamente la vettorizzazione per l'elaborazione parallela dei dati.\n
Proposto per il test un quinto prototipo preliminare dell'API per la concorrenza strutturata, che semplifica lo sviluppo di applicazioni multithread gestendo pi\u00f9 attivit\u00e0 eseguite in thread diversi come un'unica unit\u00e0.\n
Nel meccanismo di pattern matching \u00e8 stata proposta una terza opzione preliminare che consente l'uso di tipi primitivi (int, byte, char e altri tipi di base che non sono oggetti) in tutte le forme di pattern, 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 ... }\n
In JDK Flight Recorder (JFR) \u00e8 stata aggiunta la supporto sperimentale per il profiling con tracciamento pi\u00f9 accurato del consumo delle risorse CPU sulla piattaforma Linux. Le informazioni sul tempo di esecuzione delle varie costruzioni possono essere visualizzate chiaramente utilizzando grafici a colori 'FlameGraph'.\n
Migliorata la stabilit\u00e0 di JDK Flight Recorder (JFR) durante il campionamento asincrono degli stack dei thread Java, evitando di analizzare la stack trace solo nei \u00abpunti sicuri\u00bb (safepoints).\n
In JDK Flight Recorder (JFR) sono stati aggiunti strumenti per il tracciamento e la valutazione dei tempi di esecuzione dei metodi. \u00c8 supportato il tracciamento dello stack delle chiamate per metodi specifici e la registrazione di statistiche precise sulle chiamate ai metodi, coprendo metriche come il tempo di esecuzione e il numero di chiamate. <\/ul>\n