JDK 18: le nuove funzionalità di Java 18

A marzo, Java 18 incuba un'API vettoriale, visualizza in anteprima la corrispondenza dei modelli per le istruzioni switch, adotta UTF-8 come set di caratteri predefinito e include un semplice server Web.

java

Il rilascio di Java Development Kit (JDK) 18 è previsto per il 22 marzo 2022. La nuova versione di Java standard avrà nove nuove funzionalità, con il set di funzionalità bloccato a partire dal 9 dicembre.

JDK 18 è passato a una fase di rilascio candidato, dopo due fasi di rampdown condotte tra dicembre e febbraio. Una seconda release candidate è prevista per il 24 febbraio. Gli aggiornamenti a Java standard vengono rilasciati ogni sei mesi, con la versione più recente, JDK 17, in arrivo a settembre.

La pagina OpenJDK elenca le seguenti caratteristiche che prendono ufficialmente di mira JDK 18: un’interfaccia del fornitore di servizi, un semplice server web, una terza incubazione dell’API vettoriale, frammenti di codice, una reimplementazione della riflessione di base, un set di caratteri UTF-8, un secondo incubatore di una funzione esterna e un’API di memoria, una seconda anteprima della corrispondenza dei modelli per le istruzioni switch e la deprecazione della finalizzazione, che è stata l’ultima aggiunta.

Mentre JDK 17 era una versione di supporto a lungo termine (LTS) che riceverà almeno otto anni di supporto da Oracle, JDK 18 sarà una versione di funzionalità a breve termine supportata per sei mesi. È possibile trovare build di accesso anticipato di JDK 18 per Linux, Windows e MacOS su java.net.

Le specifiche delle proposte JDK 18 includono:

  • Deprecare la finalizzazione per la rimozione in una versione futura. Finalizer presenta difetti che causano problemi significativi nel mondo reale in termini di sicurezza, prestazioni, affidabilità e manutenibilità. Ha anche un modello di programmazione difficile. La finalizzazione è abilitata per impostazione predefinita per ora, ma può essere disabilitata per facilitare i test iniziali. Verrà disabilitato per impostazione predefinita in una versione delle funzionalità e rimosso del tutto in una versione successiva. La proposta richiede un’opzione della riga di comando per disabilitare la finalizzazione e la deprecazione di tutti i finalizzatori e metodi di finalizzazione nell’API Java standard. Gli obiettivi della proposta includono aiutare gli sviluppatori a comprendere i pericoli della finalizzazione, preparare gli sviluppatori alla sua eventuale rimozione e fornire strumenti semplici per aiutare a rilevare la dipendenza dalla finalizzazione. Introdotta in Java 1.0, la finalizzazione aveva lo scopo di evitare perdite di risorse. Una classe può dichiarare un finalizzatore, il metodo protected void finalize(), il cui corpo rilascia qualsiasi risorsa sottostante. Il Garbage Collector pianificherà il finalizzatore di un oggetto irraggiungibile da chiamare prima che recuperi la memoria dell’oggetto; a sua volta, il metodo finalize può eseguire azioni come chiamare la chiusura dell’oggetto. Questa sembra una rete di sicurezza efficace per prevenire perdite di risorse, ma esistono difetti tra cui latenza imprevedibile, con un lungo periodo di tempo tra quando un oggetto diventa irraggiungibile e quando viene chiamato il suo finalizzatore; comportamento non vincolato, con codice finalizzatore in grado di compiere qualsiasi azione, incluso resuscitare un oggetto e renderlo nuovamente raggiungibile; il finalizzatore è sempre abilitato, senza alcun meccanismo di registrazione esplicito; e i finalizzatori possono essere eseguiti su thread non specificati in un ordine arbitrario. Dati i problemi con la finalizzazione, si consiglia agli sviluppatori di utilizzare tecniche alternative per evitare perdite di risorse, vale a dire dichiarazioni try-with-resources e pulitori.
  • Per la SPI di risoluzione dell’indirizzo Internet, la proposta è di definire una SPI per la risoluzione dell’host e dell’indirizzo del nome in modo che Inet.Address possa utilizzare risolutori diversi dal risolutore integrato della piattaforma. Le motivazioni per questo sforzo includono una migliore abilitazione di Project Loom, per la concorrenza e nuovi modelli di programmazione in Java, insieme all’integrazione di nuovi protocolli di rete, alla personalizzazione e all’abilitazione dei test. La proposta non prevede lo sviluppo di un risolutore alternativo per il JDK.
  • Una seconda anteprima della corrispondenza dei modelli per switch, in cui il linguaggio Java verrebbe migliorato con la corrispondenza dei modelli per le espressioni e le istruzioni switch, insieme alle estensioni del linguaggio dei modelli. Ciò è stato presentato in anteprima in JDK 17. L’estensione della corrispondenza dei modelli a switch consente di testare un’espressione rispetto a una serie di modelli, ciascuno con un’azione specifica, in modo che le query complesse orientate ai dati possano essere espresse in modo conciso e sicuro./li>
  • La reimplementazione della riflessione principale con gli handle del metodo reimplementerebbe lang.reflect.Method, Constructor e Field sopra gli handle del metodo java.lang.invoke. La presenza di handle di metodo come meccanismo sottostante per la riflessione ridurrà i costi di manutenzione e sviluppo delle API java.lang.reflect e java.lang.invoke.
  • Con la semplice proposta di server Web, verrebbe fornito uno strumento da riga di comando per avviare un server Web minimo che serve solo file statici. Non sono disponibili funzionalità CGI o simili a servlet. Lo strumento sarà utile per la prototipazione, la codifica ad hoc e il test, in particolare in contesti educativi. Gli obiettivi del piano includono l’offerta di un file server HTTP statico pronto all’uso con una configurazione semplice e funzionalità minime, riducendo l’energia di attivazione degli sviluppatori e rendendo il JDK più accessibile e fornendo un’implementazione predefinita tramite la riga di comando insieme a una piccola API per la creazione e la personalizzazione del programmatic. Fornire un server ricco di funzionalità o di livello commerciale non è un obiettivo della proposta.
  • Una seconda incubazione di una funzione esterna e di un’API di memoria, in cui viene introdotta un’API attraverso la quale i programmi Java possono interoperare con codice e dati al di fuori del runtime Java. Invocando funzioni esterne – codice esterno alla JVM – e accedendo in sicurezza alla memoria esterna – memoria non gestita dalla JVM – l’API consente ai programmi Java di chiamare librerie native ed elaborare dati nativi senza la fragilità e il pericolo di JNI (Java Native Interface). L’intento è quello di sostituire JNI con un modello di sviluppo Java puro e superiore. Questa API è stata incubata in JDK 17. Per JDK 18, sarebbero stati incorporati perfezionamenti, in base al feedback, come il supporto per più vettori come Boolean e MemoryAddress negli handle var di accesso alla memoria e una nuova API per copiare gli array Java da e verso la memoria segmenti.
  • L’API vettoriale verrebbe incubata per la terza volta in JDK 18, essendo stata precedentemente incubata in JDK 16 e JDK 17. Questa proposta esprimerebbe calcoli vettoriali che compilano in fase di esecuzione per istruzioni vettoriali ottimali su architetture CPU supportate, ottenendo prestazioni superiori a equivalenti calcoli scalari. Le operazioni vettoriali esprimono un grado di parallelizzazione che consente di svolgere più lavoro su un singolo ciclo della CPU, producendo così miglioramenti significativi delle prestazioni. L’API vettoriale indipendente dalla piattaforma mira a fornire un modo per scrivere algoritmi complessi in Java, utilizzando il vettore automatico HotSpot esistente ma con un modello utente che rende più prevedibile la vettorizzazione. JDK 18 aggiungerebbe anche il supporto per la piattaforma ARM Scalar Vector Extension e migliorerebbe le prestazioni delle operazioni vettoriali che accettano maschere su architetture che supportano il mascheramento nell’hardware.
  • Specificando UTF-8 come set di caratteri predefinito delle API Java standard. UTF-8 è una codifica di caratteri a larghezza variabile per la comunicazione elettronica ed è considerato il set di caratteri standard del web. Charset è una codifica dei caratteri in grado di codificare tutti i caratteri sul Web. Attraverso questa modifica, le API che dipendono dal set di caratteri predefinito si comporteranno in modo coerente in tutte le implementazioni, i sistemi operativi, le impostazioni locali e le configurazioni. La proposta non intende definire nuove API Java standard o specifiche per JDK. I sostenitori della proposta si aspettano che le applicazioni in molti ambienti non subiranno alcun impatto dalla scelta di UTF-8 da parte di Java, poiché MacOS, molte distribuzioni Linux e molte applicazioni server supportano già UTF-8. Tuttavia, esiste il rischio in altri ambienti, il più ovvio è che le applicazioni che dipendono dal set di caratteri predefinito si comporteranno in modo errato durante l’elaborazione dei dati prodotti quando il set di caratteri predefinito non era specificato. Il danneggiamento dei dati può verificarsi silenziosamente. Si prevede che l’impatto principale riguarderà gli utenti dei sistemi Windows nelle località asiatiche e possibilmente alcuni ambienti server nelle località asiatiche e in altre località.
  • Snippet di codice nella documentazione dell’API Java, che prevede l’introduzione di un tag @snippet per il doclet standard di JavaDoc, per semplificare l’inclusione del codice sorgente di esempio nella documentazione dell’API. Tra gli obiettivi del piano c’è quello di facilitare la convalida dei frammenti di codice sorgente fornendo l’accesso API a tali frammenti. Sebbene la correttezza sia responsabilità dell’autore, il supporto avanzato in JavaDoc e strumenti correlati può semplificare l’ottenimento. Altri obiettivi includono l’abilitazione di uno stile moderno, come l’evidenziazione della sintassi, nonché il collegamento automatico dei nomi alle dichiarazioni e l’abilitazione di un migliore supporto IDE per la creazione e la modifica di frammenti. La proposta rileva che gli autori della documentazione API spesso includono frammenti di codice sorgente nei commenti alla documentazione.

Fonte: Infoworld

Post Correlati