{"id":183379,"date":"2026-09-17T16:54:20","date_gmt":"2026-09-17T14:54:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/vypusk-java-se-27-i-openjdk-27"},"modified":"2026-09-17T16:54:25","modified_gmt":"2026-09-17T14:54:25","slug":"java-se-27-and-openjdk-27-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/java-se-27-and-openjdk-27-released","title":{"rendered":"Rilasciati Java SE 27 e OpenJDK 27","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo sei mesi di sviluppo, Oracle ha rilasciato la piattaforma Java SE 27 (Java Platform, Standard Edition 27), la cui implementazione di riferimento \u00e8 il progetto aperto OpenJDK. A parte la rimozione di alcune funzionalit\u00e0 obsolete, Java SE 27 mantiene la retrocompatibilit\u00e0 con le versioni precedenti della piattaforma Java: la maggior parte dei progetti Java gi\u00e0 sviluppati continuer\u00e0 a funzionare senza modifiche quando eseguita con la nuova versione. Sono disponibili build pronte per l\u2019installazione di Java SE 27 (JDK, JRE e Server JRE) per Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). L\u2019implementazione di riferimento di Java SE 27 sviluppata nell\u2019ambito del progetto OpenJDK \u00e8 completamente open source con licenza GPLv2, con eccezioni GNU ClassPath che consentono il collegamento dinamico con prodotti commerciali. <\/p>\n
Java SE 27 rientra nella categoria delle versioni con ciclo di supporto standard, per cui gli aggiornamenti saranno pubblicati fino al rilascio successivo. Come ramo con supporto a lungo termine (LTS) si raccomanda di utilizzare Java SE 25, Java SE 21 o Java SE 17, per cui gli aggiornamenti saranno disponibili rispettivamente fino al 2033, 2031 e 2029 (quelli pubblici fino a settembre 2030, 2028 e 2026). Il supporto esteso del ramo LTS Java SE 8 proseguir\u00e0 fino al 2030, mentre quello di Java SE 11 fino al 2032. <\/p>\n
Tra le novit\u00e0 di Java SE 27 (1, 2, 3, 4): <\/p>\n
\n
Per impostazione predefinita, in tutti gli ambienti viene utilizzato il garbage collector G1 (Garbage-First), in precedenza impiegato nei sistemi server. G1 \u00e8 ottimizzato per l\u2019uso su sistemi multiprocessore con molta memoria e per bilanciare la prevedibilit\u00e0 della latenza con un\u2019elevata capacit\u00e0 di elaborazione. Durante il funzionamento, G1 suddivide la memoria in numerose piccole regioni e pulisce per prime quelle in cui sono presenti pi\u00f9 oggetti non pi\u00f9 utilizzati e meno dati attivamente in uso.\n
Nella HotSpot JVM, per impostazione predefinita, sono attive intestazioni compatte degli oggetti. La dimensione delle intestazioni sui sistemi a 64 bit \u00e8 stata ridotta da 96 a 64 bit, con una conseguente diminuzione del consumo di memoria e una maggiore probabilit\u00e0 che i dati rientrino nella cache del processore. Nei test SPECjbb2015, il consumo di memoria \u00e8 diminuito del 22%, il carico sulla CPU si \u00e8 ridotto dell\u20198% e il numero di operazioni di garbage collection \u00e8 calato del 15%. Nei test del parser JSON, il tempo di esecuzione si \u00e8 ridotto del 10%.\n
Nell\u2019implementazione di TLS 1.3 \u00e8 stato aggiunto il supporto per schemi ibridi di negoziazione delle chiavi, che combinano l\u2019algoritmo ML-KEM (CRYSTALS-Kyber), resistente agli attacchi brute-force con computer quantistici, con i classici algoritmi ECDHE basati su curve ellittiche: X25519MLKEM768 (ECDHE con curva X25519 + ML-KEM-768), SecP256r1MLKEM76 (ECDHE con curva secp256r1 + ML-KEM-768) e SecP384r1MLKEM1024 (ECDHE con curva secp384r1 + ML-KEM-1024). Nell\u2019API javax.net.ssl<\/a> Questi schemi sono abilitati per impostazione predefinita e non richiedono modifiche alle applicazioni per essere utilizzati.\n