Oracle ha reso disponibile Java 27, nuova release semestrale della piattaforma Java che interviene soprattutto su crittografia post-quantistica, gestione della memoria, concorrenza, diagnostica e calcolo vettoriale. Il rilascio comprende nove JDK Enhancement Proposal (JEP), mentre l’ecosistema si aggiorna in parallelo con JavaFX 27, Helidon 27 e Oracle Jipher 20.
A oltre trent’anni dalla sua introduzione, Java continua a mantenere una base d’uso molto ampia. Nella Developer Survey 2025 di Stack Overflow è stato utilizzato nell’ultimo anno dal 29,4% dei rispondenti e dal 29,6% degli sviluppatori professionisti. I dati di GitHub Octoverse 2025 mostrano inoltre che Java è il quarto linguaggio per numero di contributor, dietro TypeScript, Python e JavaScript: tra agosto 2024 e agosto 2025 ha aggiunto circa 175.000 contributor, con una crescita del 20,7%, ed è stato il linguaggio principale di circa 3,52 milioni di nuovi repository creati nello stesso periodo.
La dinamica è diversa da quella di Python e TypeScript, più direttamente trainati rispettivamente dall’AI e dallo sviluppo web moderno, ma indica che Java non vive soltanto della propria base installata. GitHub associa la sua crescita soprattutto allo sviluppo enterprise, un’area nella quale il linguaggio continua a essere utilizzato per backend, microservizi, sistemi distribuiti e applicazioni business-critical.
Java 27 arriva sei mesi dopo Java 26 e prosegue il ciclo di rilascio semestrale di OpenJDK. È una release non-LTS, nel modello che alterna versioni semestrali ordinarie a release con Long-Term Support a cadenza biennale. Dopo Java 25, pubblicato nel settembre 2025 come versione LTS, Java 26 e Java 27 sono quindi release intermedie; la roadmap di supporto di Oracle indica Java 29, previsto per settembre 2027, come prossimo LTS.
Le novità tecniche di Java 27 seguono direttrici diverse. Alcune diventano impostazioni standard della Java Virtual Machine (JVM), altre proseguono un percorso di incubazione o preview iniziato nelle release precedenti. Sul fronte della sicurezza compare inoltre un nuovo meccanismo per combinare crittografia tradizionale e post-quantistica nelle connessioni TLS.
TLS 1.3 prepara Java alla crittografia post-quantistica
La novità più direttamente legata alla sicurezza è la JEP 527, che introduce il Post-Quantum Hybrid Key Exchange per TLS 1.3.
Lo scambio ibrido combina un meccanismo crittografico classico con ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), l’algoritmo post-quantistico standardizzato dal NIST. I due meccanismi concorrono alla generazione del segreto condiviso utilizzato per proteggere la sessione TLS 1.3.
La sicurezza della sessione deriva così dalla combinazione di due meccanismi fondati su presupposti matematici differenti. Se in futuro emergesse una debolezza in ML-KEM, continuerebbe a operare la protezione offerta dalla componente crittografica classica; se invece un computer quantistico sufficientemente potente rendesse vulnerabile quest’ultima, la componente post-quantistica continuerebbe a proteggere il segreto condiviso. Per compromettere la sessione sarebbe quindi necessario superare entrambi i meccanismi.
Questa protezione risponde anche al rischio definito harvest now, decrypt later: un attaccante può intercettare e conservare oggi comunicazioni cifrate per tentare di decifrarle in futuro, quando la disponibilità di computer quantistici sufficientemente potenti potrebbe rendere vulnerabili alcuni degli algoritmi asimmetrici attualmente utilizzati. Per informazioni destinate a mantenere valore o riservatezza per molti anni — proprietà intellettuale, dati finanziari, informazioni sanitarie o comunicazioni aziendali sensibili — la transizione alla crittografia post-quantistica deve quindi iniziare prima che tali sistemi siano effettivamente disponibili.
L’approccio ibrido consente inoltre una migrazione graduale. Le organizzazioni possono introdurre algoritmi resistenti agli attacchi quantistici continuando a utilizzare le infrastrutture e i meccanismi crittografici già adottati, evitando una sostituzione simultanea dell’intero impianto di sicurezza. In questa fase di transizione, la componente classica conserva le garanzie di una tecnologia ampiamente collaudata, mentre quella post-quantistica aggiunge protezione rispetto al rischio futuro rappresentato dal calcolo quantistico.
Con JDK 27 questo meccanismo entra direttamente nell’implementazione TLS 1.3 del JDK e completa un percorso iniziato nelle release precedenti con l’introduzione di ML-KEM e ML-DSA. Oracle prevede inoltre di estendere progressivamente queste capacità alle versioni JDK con supporto a lungo termine.
Prosegue anche il lavoro sulle codifiche PEM degli oggetti crittografici con la JEP 538, arrivata alla terza preview. L’obiettivo è fornire API Java standard per codificare e decodificare chiavi, certificati e altro materiale crittografico nel formato PEM, molto diffuso negli strumenti e nelle infrastrutture di sicurezza.
Java Flight Recorder può oscurare i dati sensibili prima di registrarli
Un intervento meno visibile, ma significativo negli ambienti enterprise, riguarda Java Flight Recorder (JFR), il sistema integrato nel JDK per raccogliere dati diagnostici e di profiling sulle applicazioni in esecuzione.
La JEP 536, JFR In-Process Data Redaction, introduce la possibilità di oscurare informazioni sensibili prima che vengano scritte nelle registrazioni JFR.
La distinzione è importante: nei sistemi di produzione le registrazioni diagnostiche possono contenere nomi, identificatori, stringhe applicative o altre informazioni che sarebbe problematico trasferire a team di supporto o conservare nei sistemi di osservabilità.
La redazione effettuata all’interno del processo consente di mantenere le informazioni utili all’analisi delle prestazioni e degli errori limitando l’esposizione dei dati che non devono uscire dall’applicazione. Il meccanismo può quindi essere rilevante negli ambienti sottoposti a requisiti di privacy e conformità, oltre che nelle applicazioni che elaborano grandi quantità di dati aziendali.
La Vector API arriva al dodicesimo ciclo di incubazione
Java continua contemporaneamente a lavorare sull’accesso alle istruzioni vettoriali delle CPU. La Vector API, JEP 537, raggiunge con Java 27 il dodicesimo ciclo come API incubator.
L’API permette agli sviluppatori di esprimere calcoli vettoriali che la JVM può tradurre nelle istruzioni SIMD (Single Instruction, Multiple Data) disponibili sul processore, evitando di ricorrere direttamente a codice nativo specifico per una determinata architettura.
Il principio è eseguire la stessa operazione contemporaneamente su più elementi di un vettore anziché elaborarli uno alla volta. È un modello utile in elaborazioni numeriche, multimedia, analytics, machine learning e in altre attività ad alta intensità di calcolo.
La lunga permanenza nell’incubator riflette anche la complessità del progetto: l’API deve mantenere la portabilità tipica di Java e al tempo stesso sfruttare efficacemente set di istruzioni differenti sulle varie architetture hardware.
Structured Concurrency continua il percorso verso un modello stabile
Un’altra API ormai presente da diverse release è la Structured Concurrency, che con la JEP 533 arriva alla settima preview.
L’idea è trattare un insieme di task concorrenti collegati logicamente come una singola unità di lavoro. Se un servizio deve, per esempio, interrogare contemporaneamente più sorgenti e utilizzare tutti i risultati per costruire una risposta, le operazioni possono essere create, attese, cancellate e gestite all’interno dello stesso perimetro.
Questo modello rende più prevedibile il comportamento in caso di errori o cancellazioni e semplifica l’osservazione dei thread coinvolti. La Structured Concurrency si inserisce nel più ampio lavoro avviato con i virtual thread, diventati una funzionalità stabile di Java con JDK 21.
Per applicazioni distribuite e microservizi il vantaggio riguarda soprattutto la gestione di workflow composti da numerose operazioni I/O concorrenti: chiamate HTTP, accesso a database, interrogazione di servizi remoti e chiamate parallele a modelli e servizi di AI.
Pattern matching e tipi primitivi diventano più uniformi
La JEP 532, alla quinta preview, estende l’utilizzo dei tipi primitivi nei pattern, nell’operatore instanceof e negli statement e nelle expression switch.
Java ha progressivamente ampliato il pattern matching nelle ultime versioni, riducendo la quantità di codice necessario per analizzare valori e strutture dati. L’estensione ai primitivi cerca di rendere questo modello più uniforme, evitando differenze artificiali tra il trattamento di oggetti e valori come int, long, float o double.
Il cambiamento interessa in particolare applicazioni che combinano strutture a oggetti e grandi quantità di dati numerici, ma costituisce soprattutto un ulteriore passo nell’evoluzione sintattica del linguaggio.
Alla terza preview arrivano invece le Lazy Constants della JEP 531. Il meccanismo consente di dichiarare valori che vengono inizializzati soltanto al primo utilizzo, mantenendo successivamente il comportamento di una costante.
È una soluzione utile quando la costruzione di un oggetto è costosa ma potrebbe non essere necessaria durante ogni esecuzione dell’applicazione: si evita così di occupare memoria e consumare tempo di CPU in fase di inizializzazione senza rinunciare alle garanzie offerte da un valore immutabile dopo la sua creazione.
Compact Object Headers diventano l’impostazione predefinita
Due JEP intervengono direttamente sul comportamento della JVM e, a differenza delle API in preview, diventano parte del funzionamento ordinario di Java 27.
La JEP 534 abilita per impostazione predefinita i Compact Object Headers, una tecnica che riduce lo spazio occupato dall’header associato a ciascun oggetto Java nell’heap.
Il risparmio per un singolo oggetto può apparire limitato, ma nelle applicazioni che mantengono in memoria milioni di oggetti può tradursi in una riduzione significativa del memory footprint. Una minore occupazione dell’heap può a sua volta consentire una maggiore densità delle applicazioni sulla stessa infrastruttura e diminuire la pressione sul garbage collector.
Java 27 modifica anche la configurazione predefinita del garbage collection. Con la JEP 523, G1 diventa il garbage collector predefinito in tutti gli ambienti supportati.
L’obiettivo è eliminare differenze di comportamento dovute alla selezione automatica di garbage collector differenti in funzione delle caratteristiche dell’ambiente, rendendo più prevedibile il passaggio delle applicazioni tra sistemi di sviluppo, container e infrastrutture di produzione.
Java 27 aggiorna anche Helidon, JavaFX e Jipher
Il rilascio del JDK è accompagnato dall’aggiornamento di diversi componenti del Java Verified Portfolio, l’insieme di tecnologie Java per le quali Oracle coordina compatibilità, roadmap e supporto commerciale.
Helidon 27, framework Java open source per lo sviluppo di microservizi cloud-native, continua a basare il proprio modello di concorrenza sui virtual thread. La nuova versione utilizza anche gli Scoped Values e amplia le API dichiarative con moduli per gRPC e messaging.
Il nuovo Helidon Messaging introduce un’astrazione per sviluppare applicazioni senza legare il codice a uno specifico sistema di messaggistica, attraverso connettori per tecnologie tra cui Kafka e Java Message Service (JMS). Helidon Data JDBC propone invece uno strato leggero per l’accesso ai database relazionali lasciando allo sviluppatore un maggiore controllo sull’SQL.
Con questa versione anche la numerazione e la cadenza dei rilasci di Helidon vengono allineate a OpenJDK, rendendo immediatamente riconoscibile la corrispondenza fra le rispettive generazioni.
JavaFX 27 aggiorna il framework per applicazioni client Java. Tra le modifiche figura una pipeline di rendering basata su Metal su macOS, insieme a interventi sui controlli di editing del testo e sull’accessibilità.
Entra inoltre nel Java Verified Portfolio Oracle Jipher 20, che mette a disposizione delle applicazioni Java un modulo crittografico OpenSSL validato secondo FIPS 140-3, standard statunitense utilizzato per la certificazione dei moduli crittografici.
Jipher 20 aggiunge il supporto agli algoritmi post-quantistici ML-KEM e ML-DSA, ai meccanismi KDF e HKDF attraverso le API standard di Java e, a partire da JDK 25, utilizza la Foreign Function and Memory API per l’integrazione con OpenSSL.
JDK 28 apre la strada a Project Valhalla
Contemporaneamente a Java 27, Oracle richiama l’attenzione sulle build early access di JDK 28, nelle quali comincia una delle fasi più importanti di Project Valhalla.
Valhalla affronta uno dei limiti strutturali storici del modello dei dati di Java: la separazione tra oggetti e tipi primitivi. Gli oggetti offrono identità, riferimenti e le altre caratteristiche del modello object-oriented, ma questa rappresentazione introduce un costo in termini di memoria e accessi indiretti; i primitivi sono invece molto più compatti, ma non partecipano allo stesso modo al sistema dei tipi.
Il progetto introduce progressivamente value class e value object, con l’intento di consentire rappresentazioni dei dati più dense ed efficienti mantenendo il modello di programmazione Java. L’impatto potenziale è significativo soprattutto quando vengono gestite grandi collezioni di piccoli oggetti o strutture numeriche, come avviene in analytics, calcolo scientifico, applicazioni finanziarie e machine learning.
Non si tratta ancora di una funzionalità pronta per l’uso generale in produzione: la presenza nelle build early access di JDK 28 permette agli sviluppatori di sperimentare le modifiche prima della loro stabilizzazione.
In parallelo continua Project Leyden, il progetto che punta a ridurre il tempo necessario per l’avvio delle applicazioni Java, quello richiesto per raggiungere le massime prestazioni e l’occupazione di memoria. Tra le tecniche utilizzate rientra la compilazione ahead-of-time (AOT), che sposta parte del lavoro normalmente svolto dalla JVM durante l’esecuzione a una fase precedente.
Valhalla e Leyden intervengono così su due aspetti centrali nell’evoluzione della piattaforma: la rappresentazione dei dati e il costo dell’avvio e del warm-up della JVM. Java 27 si colloca lungo questo percorso, mentre le build di JDK 28 consentono già di osservare alcune delle modifiche destinate alle prossime generazioni della piattaforma.
