JDK 12: le nuove funzionalità di Java 12

La versione di produzione di Java Development Kit 12, basata su Java SE (Standard Edition) 12, è ora disponibile. Le build JDK 12 sono disponibili da Oracle per Linux, Windows e MacOS. 

Dove scaricare JDK 12

È possibile scaricare JDK 12 dal sito Web Java.net.

Le build open source sono fornite sotto la GNU General Public License v2, con Classpath Eccezione. Le build commerciali di JDK 12 di Oracle possono essere trovate sulla rete Oracle Technology con una licenza non open source.

Nuove funzionalità in Java 12

Shenandoah netturbino

Java 12 aggiunge Shenandoah, un algoritmo sperimentale per la raccolta dei rifiuti, per ridurre i tempi di pausa della raccolta dei rifiuti eseguendo il lavoro di evacuazione contemporaneamente all'esecuzione di thread Java. Shenandoah fornisce un algoritmo appropriato per applicazioni che valorizzano la reattività e le brevi pause prevedibili. Tuttavia, l'intento non è quello di risolvere tutti i problemi di pausa di JVM.

Red Hat attualmente supporta Shenandoah sulle architetture Aarch64 e AMD64.

Collezioni miste abili per il garbage collector G1

Java 12 rende compatibili le raccolte miste G1 se superano l'obiettivo di pausa. Uno degli obiettivi di G1 era soddisfare un obiettivo di tempo di pausa fornito dall'utente per le pause di raccolta.

In precedenza, un motore di analisi avanzato selezionava la quantità di lavoro da svolgere durante una raccolta. Il risultato è stato un insieme di regioni noto come insieme di raccolta. Una volta che il set è stato determinato e la raccolta è iniziata, G1 ha raccolto tutti gli oggetti vivi nelle regioni delle collezioni in tutte le regioni senza fermarsi. Ma questo potrebbe portare G1 a superare l'obiettivo del tempo di pausa se l'euristica di un'applicazione ha scelto un set di raccolta troppo grande.

Era necessario un meccanismo per rilevare quando l'euristica seleziona ripetutamente una quantità di lavoro errata per le raccolte e, in tal caso, fare in modo che G1 esegua il lavoro di raccolta in modo incrementale nei passaggi, in cui la raccolta potrebbe essere interrotta dopo ogni passaggio. Il meccanismo introdotto in Java 12 consente a G1 di raggiungere l'obiettivo del tempo di pausa più spesso.

Pronta restituzione della memoria impegnata inutilizzata

Java 12 migliora G1 per restituire automaticamente la memoria heap Java al sistema operativo quando è inattivo. Questa memoria viene rilasciata in un periodo di tempo ragionevole quando l'attività dell'applicazione è molto bassa.

In precedenza, G1 restituiva la memoria dall'heap solo durante una procedura di Garbage Collection completa o durante un ciclo simultaneo. Con G1 che cerca di evitare la raccolta completa dei rifiuti, attivando solo un ciclo simultaneo basato sull'occupazione dell'heap e sull'attività di allocazione, in molti casi non restituirà la memoria dell'heap a meno che non sia costretto a farlo esternamente. Questo comportamento era svantaggioso negli ambienti container in cui le risorse vengono pagate in base all'utilizzo. Anche quando la JVM utilizza solo una frazione della sua memoria assegnata a causa dell'inattività, G1 ha mantenuto l'heap completo. Pertanto, i clienti hanno sempre pagato per tutte le risorse ei provider di servizi cloud non potevano utilizzare appieno il proprio hardware.

Con Java 12, la JVM può rilevare le fasi di sottoutilizzo dell'heap e ridurre automaticamente il suo utilizzo dell'heap durante quel periodo. 

API delle costanti JVM

Questa API modella le descrizioni nominali del file della classe chiave e degli artefatti di runtime, in particolare le costanti caricabili dal pool di costanti. Java 12 definisce una famiglia di tipi di riferimento simbolico basati sul valore in un nuovo pacchetto java.lang.invoke.constant, per descrivere ogni tipo di costante caricabile.

I pool di costanti esistono in ogni classe Java, memorizzando operandi e istruzioni bytecode nella classe. Le voci nel pool di costanti descrivono artefatti di runtime come classi e metodi o valori semplici come stringhe e numeri interi. Queste voci sono note come costanti caricabili.

I programmi che manipolano i file di classe devono modellare le istruzioni bytecode e a loro volta le costanti caricabili. Tuttavia, l'utilizzo di tipi Java standard per modellare costanti caricabili è inadeguato. Questo può essere accettabile per una costante caricabile che descrive una stringa, ma è problematico per una costante caricabile che descrive una classe, perché la produzione di un Classoggetto "live" si basa sulla correttezza e coerenza del caricamento della classe. Il caricamento delle classi, tuttavia, ha molte dipendenze ambientali e modalità di errore.

Quindi, i programmi che si occupano di costanti caricabili potrebbero essere semplificati se potessero manipolare classi e metodi e artefatti meno conosciuti come le maniglie dei metodi e le costanti calcolate dinamicamente in una forma simbolica nominale. Pertanto, l'API delle costanti JVM fornisce alle librerie e agli strumenti un unico modo standard per descrivere le costanti caricabili.

Avvio, CDS e Garbage Collection migliorati

Java 12 migliora il processo di compilazione JDK per generare un archivio CDS (Class Data Sharing) predefinito, utilizzando l'elenco di classi predefinito, su piattaforme a 64 bit. Ciò migliora il tempo di avvio immediato ed elimina la necessità di eseguire -Xshare:dumpper beneficiare del CDS. Il processo di compilazione JDK è stato modificato per essere eseguito java-xshare:dumpdopo aver collegato l'immagine.

Sono state incluse ulteriori opzioni della riga di comando per ottimizzare i tempi di heap della garbage collection per migliorare il layout della memoria per i casi comuni. Gli utenti con requisiti più avanzati, come elenchi di classi personalizzate che includono classi di applicazioni e diverse configurazioni di raccolta dati inutili, possono ancora creare un archivio CDS personalizzato.

Numero ridotto di porte ARM

Java 12 rimuove tutte le fonti relative alla arm64porta mantenendo l'ARM a 32 bit e 64 bit aarch64. La rimozione di questa porta consentirebbe ai contributori di concentrare gli sforzi su una singola implementazione ARM a 64 bit ed eliminare il lavoro duplicato che risulterebbe dal mantenimento di due porte. Attualmente, due porte ARM a 64 bit sono nel JDK.

Cambia espressioni

Le espressioni di commutazione semplificano la codifica estendendo l' switchistruzione in modo che possa essere utilizzata come istruzione o espressione. Ciò consente sia alle istruzioni che alle espressioni di utilizzare l'ambito e il comportamento del flusso di controllo "tradizionale" o "semplificato". Questi cambiamenti si traducono in una codifica "quotidiana" più semplice e preparano la strada per l'uso del pattern matching in switch.

Poiché i costruttori di Java si switchstanno muovendo per supportare la corrispondenza dei modelli, le irregolarità dell'istruzione Java  sono diventate degli impedimenti. Questi includono il comportamento del flusso di controllo predefinito dei blocchi di interruttori; ambito predefinito dei blocchi switch, in cui il blocco viene trattato come un unico ambito; e switch funziona solo come una dichiarazione. L'attuale progettazione switchdell'istruzione di Java segue da vicino linguaggi come C ++ e, per impostazione predefinita, supporta la semantica fallthrough. Questo flusso di controllo è stato utile per scrivere codice di basso livello. Ma quando lo switch viene utilizzato in contesti di livello superiore, la sua natura soggetta a errori inizia a superare la flessibilità.

Suite di benchmark di base

JDK 12 include una suite di base di microbenchmark, che sono stati aggiunti al codice sorgente della piattaforma. L'obiettivo è rendere più semplice per gli sviluppatori eseguire benchmark esistenti o crearne di nuovi.

La proposta della suite di microbenchmark, creata a luglio 2014 e aggiornata all'inizio di novembre 2018, è stata sostenuta da Java Microbenchmark Harness (JMH), per la creazione di benchmark scritti in Java e altri linguaggi JVM. La suite è collocata con il codice sorgente JDK in una singola directory, con gli sviluppatori in grado di aggiungere facilmente nuovi benchmark.

Non era un obiettivo fornire benchmark per nuove funzionalità JDK o creare un set completo di benchmark che coprisse tutto nel JDK. Si noti inoltre che la suite di benchmarking non è richiesta per le build JDK regolari ma è un obiettivo di build separato. 

La proposta prevedeva la creazione di una nuova pagina su wiki.openjdk.java.net per spiegare come sviluppare benchmark e descrivere i requisiti. Questi requisiti imporranno l'adesione agli standard di codifica, prestazioni riproducibili e documentazione.

Aggiornamenti JDK 12

I piani prevedono che JDK 12 riceva due aggiornamenti prima di essere sostituito da JDK 13 in sei mesi. JDK 12 fa parte della cadenza di rilascio di sei mesi di Oracle introdotta con JDK 9 a settembre 2017. JDK 12 è caratterizzata come una versione di funzionalità, a differenza di JDK 11, che è una versione di supporto a lungo termine con diversi anni di supporto pianificato.