Java 27 è arrivato, e cambia due default che riguardano tutti

Il 15 settembre 2026 Oracle ha rilasciato Java 27 (JDK 27), la nuova release a cadenza semestrale del linguaggio. Come spesso accade con le versioni “dispari” del ciclo a sei mesi, non è la release con il maggior numero di feature preview eclatanti, ma introduce due cambiamenti strutturali che meritano attenzione da parte di chi gestisce applicazioni Java in produzione: il garbage collector G1 diventa il default in ogni ambiente, e arriva il supporto nativo a scambi di chiavi TLS 1.3 resistenti al calcolo quantistico. Sono esattamente il tipo di cambiamenti “silenziosi” che possono modificare il comportamento di un’applicazione senza che una sola riga di codice venga toccata.

JEP 523: G1 diventa il garbage collector di default ovunque

Da JDK 9, G1 (Garbage-First) è il collector di default negli ambienti “server”, mentre le JVM avviate in configurazioni più leggere o vincolate in termini di risorse ricadevano sul Serial Collector, storicamente più economico in termini di footprint di memoria e tempo di avvio ma limitato a un singolo thread di collezione.

Con JEP 523, questa distinzione sparisce: G1 diventa il default in tutti gli ambienti, incluse le configurazioni precedentemente riservate a Serial. La motivazione tecnica dichiarata dal team OpenJDK è che il lavoro di ottimizzazione degli ultimi anni ha reso G1 “competitivo con Serial a qualsiasi dimensione di heap”, con throughput, latenza, footprint di memoria e tempo di startup comparabili anche sui carichi più piccoli — lo scenario in cui Serial aveva storicamente il vantaggio più netto.

Per chi amministra JVM in produzione, questo significa in pratica:

• Se non specificate esplicitamente un collector con -XX:+UseSerialGC, -XX:+UseParallelGC o -XX:+UseZGC, dopo l’upgrade a Java 27 la vostra applicazione userà G1 anche in scenari dove prima girava su Serial — ad esempio container con limiti di memoria molto stretti o microservizi con heap ridotti.
• G1 introduce collezione a più thread e fasi concorrenti che Serial non ha: aspettatevi un pattern di utilizzo CPU leggermente diverso durante i cicli di garbage collection, specialmente su ambienti con pochi core disponibili.
• Se avete pipeline di test delle performance o SLA di latenza stretti su servizi con footprint minimo (ad esempio funzioni serverless o batch job short-lived), vale la pena ripetere un benchmark mirato prima di fare l’upgrade in produzione, anche se il team OpenJDK dichiara di non aver osservato regressioni significative.
• Per tornare al comportamento precedente è sufficiente il flag esplicito -XX:+UseSerialGC in fase di avvio della JVM: nessuna riscrittura di codice necessaria.

Va inoltre ricordato che da JDK 24 le Compact Object Headers (JEP 450, poi consolidate) sono considerate stabili e restano attive di default anche in Java 27: l’header degli oggetti passa da 96 a 64 bit su architetture a 64 bit, con benefici diretti su densità di deployment, località dei dati in cache e footprint complessivo dell’heap. Combinato con G1 come default universale, il risultato netto è una JVM pensata per comportarsi in modo più uniforme sia su un server con centinaia di GB di heap sia su un container Kubernetes con 256 MB di limite.

JEP 527: scambio di chiavi TLS 1.3 ibrido e resistente al quantum computing

La seconda novità di rilievo riguarda la sicurezza delle comunicazioni. JEP 527 introduce nelle API javax.net.ssl il supporto a schemi di scambio di chiavi ibridi per TLS 1.3, che combinano un algoritmo classico basato su curve ellittiche con un algoritmo post-quantistico basato su reticoli (ML-KEM, standardizzato da NIST).

La motivazione non è ipotetica: il problema noto come “harvest now, decrypt later” descrive una minaccia già attuale, in cui traffico cifrato oggi con algoritmi classici viene intercettato e archiviato da attori con risorse importanti, in attesa che un futuro computer quantistico sufficientemente potente permetta di decifrarlo retroattivamente. Per dati con un valore di confidenzialità che si estende su anni — cartelle cliniche, segreti industriali, comunicazioni governative — agire ora, prima che il quantum computing su scala sia disponibile, è l’unica strategia sensata.

Uno schema ibrido ha una proprietà rassicurante per chi deve fidarsi della crittografia oggi: rimane sicuro finché almeno uno dei due algoritmi componenti resiste, offrendo quindi il meglio di entrambi i mondi senza scommettere tutto sulla novità.

I tre gruppi supportati

JEP 527 introduce tre nuovi “named group” per TLS 1.3, ciascuno combinazione di ECDHE classico e ML-KEM:

• X25519MLKEM768 — Curve25519 + ML-KEM-768
• SecP256r1MLKEM768 — curva secp256r1 + ML-KEM-768
• SecP384r1MLKEM1024 — curva secp384r1 + ML-KEM-1024, il livello di sicurezza più alto

L’ordine di preferenza di default della JVM diventa: X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192. In altre parole, X25519MLKEM768 ha la priorità più alta: se sia client che server supportano TLS 1.3 su Java 27 senza configurazioni personalizzate, lo scambio di chiavi ibrido post-quantistico viene negoziato automaticamente, senza alcuna modifica al codice applicativo.

Come controllare o disabilitare il comportamento

Chi ha bisogno di un controllo più fine — ad esempio per motivi di compatibilità con sistemi legacy o per test di interoperabilità — può intervenire in due modi.

Via system property, per sovrascrivere globalmente l’elenco dei gruppi supportati:

-Djdk.tls.namedGroups="secp256r1,x25519"

Oppure programmaticamente, tramite SSLParameters, per un controllo puntuale sulla singola connessione:

SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
    getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();
params.setNamedGroups(new String[] {
    "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
});
tlsSock.setSSLParameters(params);

Un punto operativo da non sottovalutare: i messaggi TLS ClientHello che negoziano questi gruppi ibridi sono più grandi rispetto a quelli con solo curve ellittiche classiche, per via delle chiavi pubbliche ML-KEM più voluminose. Se avete middlebox, load balancer o proxy TLS datati che fanno parsing rigido dei pacchetti ClientHello, vale la pena verificarne il comportamento prima del rollout su larga scala — è un problema già osservato in altri ecosistemi (browser, OpenSSH) nella fase di adozione del PQC ibrido.

Altre novità degne di nota

• JEP 533 — Structured Concurrency (settima preview): il modello che tratta gruppi di task correlati eseguiti su thread diversi come un’unica unità di lavoro continua la sua maturazione, riducendo i rischi di thread leak e semplificando cancellazione e gestione degli errori nei flussi concorrenti. Resta in preview, quindi da usare con il flag --enable-preview e non ancora adatta a codice di produzione stabile.
• JEP 532 — Primitive Types in Patterns (quinta preview): estende il pattern matching ai tipi primitivi, avvicinando ulteriormente la maturazione di questa funzionalità.
• JEP 537 — Vector API (dodicesimo incubator): continua il lungo percorso di incubazione delle API vettoriali per carichi di data analytics e inferenza AI, pensate per sfruttare le istruzioni SIMD della CPU.

Cosa significa per chi pianifica un upgrade

Nessuna delle due novità principali richiede modifiche al codice applicativo, ma entrambe cambiano comportamenti impliciti su cui molti team non hanno mai dovuto ragionare esplicitamente. Prima di un upgrade a Java 27 in produzione, ha senso:

• Verificare quale garbage collector state effettivamente usando oggi (spesso implicito, mai impostato esplicitamente) e ripetere un test di carico rappresentativo dopo l’upgrade, specialmente su servizi con heap piccoli o vincoli di latenza stretti.
• Testare l’interoperabilità TLS con eventuali componenti di rete intermedi (load balancer, WAF, proxy) prima di esporre servizi che useranno automaticamente lo scambio di chiavi ibrido.
• Se la vostra organizzazione ha requisiti di conformità legati alla crittografia post-quantistica (settore finanziario, sanitario, pubblica amministrazione), Java 27 offre finalmente un percorso “out of the box” senza dover ricorrere a provider crittografici di terze parti.

Nel complesso, Java 27 conferma una tendenza già vista in altri runtime e protocolli (OpenSSH, i principali browser): la crittografia post-quantistica sta passando rapidamente da tema di ricerca a default silenzioso nelle piattaforme che usiamo ogni giorno. Vale la pena arrivarci preparati, piuttosto che scoprirlo il giorno dell’upgrade.

Fonte: Oracle Java Blog – The Arrival of Java 27, con approfondimenti da Phoronix e dalle specifiche ufficiali JEP 523 e JEP 527 su OpenJDK.org.