Mark Reinhold, Chief Architect di Java, ha reso noto che JDK 24 è entrato nella cosiddetta Rampdown Phase Two. Le funzionalità previste per questa release sono quindi da considerarsi "frozen" e non verranno modificate ulteriormente. La versione finale di JDK 24 è programmata per il 18 marzo 2025 e non sarà una release con supporto a lungo termine. La prossima LTS in calendario è infatti JDK 25, attesa per il 16 settembre 2025.
Java 24: le funzionalità attese
JDK 24 introduce diverse JEP (Java Enhancement Proposals) di cui due sperimentali e otto in diverse fasi di anteprima. Una modifica rilevante riguarda la rimozione del supporto per Windows su architettura a 32-bit x86. Questa decisione punta a semplificare l'infrastruttura di build e test del JDK. Altre piattaforme a 32 bit, come per esempio ARM32, continueranno a essere supportate mentre il porting per Linux 32-bit x86 sarà deprecato. Con una rimozione in via definitiva pianificata entro il rilascio di JDK 25.
Un'altra novità riguarda l'introduzione di avvisi per l'utilizzo della JNI (Java Native Interface), il metodo tradizionale utilizzato per chiamare codice nativo come librerie scritte in C. A questo proposito è bene precisare che non vi sarebbe alcuna intenzione di deprecare JNI. L'obiettivo è invece quello di fornire un livello coerente di avvisi sia per JNI che per la nuova API FFM (Foreign Function and Memory). In futuro, gli sviluppatori dovranno però abilitare esplicitamente l'uso di JNI e dell'FFM API all'avvio.
Viene poi introdotto un avviso al primo utilizzo di qualsiasi metodo di accesso alla memoria nel namespace sun.misc.Unsafe
. Questi metodi sono già deprecati, saranno rimossi a partire da JDK 26 e il loro utilizzo genererà un'eccezione. Gli sviluppatori sono quindi incoraggiati a migrare verso le API standard.
Miglioramenti delle performance e sicurezza
Per quanto riguarda le prestazioni, JDK 24 migliora i tempi di avvio precaricando le classi in anticipo. Durante l'esecuzione di un'applicazione esse vengono monitorate e memorizzate nella cache per essere disponibili immediatamente al successivo avvio.
Da segnalare anche la disabilitazione permanentemente del Security Manager. Presente fin dalla prima release di Java, esso tratta tutto il codice come non attendibile per impostazione predefinita. La sua disabilitazione punta quindi a ridurre le complessità in fase di sviluppo.
Completano il quadro dei moduli per l'incapsulamento delle chiavi pensati per mitigare i rischi associati alla sicurezza crittografica e legati al calcolo quantistico.