{"id":99453,"date":"2021-03-17T04:22:35","date_gmt":"2021-03-17T02:22:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-16"},"modified":"2021-03-17T04:22:35","modified_gmt":"2021-03-17T02:22:35","slug":"vypusk-java-se-16","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-java-se-16","title":{"rendered":"Uscita di Java SE 16","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo sei mesi di sviluppo, Oracle ha rilasciato la piattaforma Java SE 16 (Java Platform, Standard Edition 16), di cui utilizza come implementazione di riferimento il progetto open source OpenJDK. In Java SE 16 \u00e8 mantenuta la compatibilit\u00e0 retroattiva con le versioni precedenti della piattaforma Java; tutti i progetti Java scritti in precedenza funzioneranno senza modifiche quando eseguiti con la nuova versione. Le versioni pronte per l'installazione di Java SE 16 (JDK, JRE e Server JRE) sono disponibili per Linux (x86_64, AArch64), Windows e macOS. L'implementazione di riferimento di Java 16, sviluppata nell'ambito del progetto OpenJDK, \u00e8 completamente open source sotto licenza GPLv2 con eccezioni GNU ClassPath, che consentono il collegamento dinamico con prodotti commerciali. <\/p>\n
Java SE 16 \u00e8 classificato tra le versioni con supporto standard, con aggiornamenti che verranno rilasciati fino al successivo rilascio. Per una versione con supporto a lungo termine (LTS), si consiglia di utilizzare Java SE 11, con aggiornamenti previsti fino al 2026. Il prossimo rilascio LTS \u00e8 previsto per settembre 2021. Ricordiamo che a partire dal rilascio di Java 10, il progetto ha adottato un nuovo processo di sviluppo, caratterizzato da un ciclo di rilascio pi\u00f9 breve. La nuova funzionalit\u00e0 viene ora sviluppata in un master branch aggiornato regolarmente, nel quale vengono inclusi i cambiamenti gi\u00e0 pronti e dal quale si diramano ogni sei mesi rami per la stabilizzazione delle nuove versioni. <\/p>\n
Nella preparazione della nuova versione, lo sviluppo \u00e8 stato trasferito dal sistema di gestione delle versioni Mercurial a Git e alla piattaforma di collaborazione GitHub. Ci si aspetta che la migrazione migliori le prestazioni delle operazioni con il repository, aumenti l'efficienza dell'archiviazione, garantisca l'accesso alle modifiche in tutta la storia del progetto, migliori il supporto alla revisione del codice e utilizzi le API per automatizzare i flussi di lavoro. Inoltre, l'uso di Git e GitHub rende il progetto pi\u00f9 attraente per i principianti e per gli sviluppatori abituali di Git. <\/p>\n
Tra le novit\u00e0 di Java 16, si possono notare: <\/p>\n
\n
Aggiunto il modulo sperimentale jdk.incubator.vector con l'implementazione dell'API Vector, che offre funzioni per calcoli vettoriali eseguiti utilizzando le istruzioni vettoriali dei processori x86_64 e AArch64, consentendo di applicare operazioni simultaneamente a pi\u00f9 valori (SIMD). A differenza delle capacit\u00e0 di auto-vettorializzazione delle operazioni scalari fornite dal compilatore JIT HotSpot, la nuova API consente di gestire esplicitamente la vettorializzazione per l'elaborazione parallela dei dati.\n
Nel codice JDK e VM HotSpot, scritto in C++, \u00e8 permesso utilizzare le funzionalit\u00e0 introdotte dalla specifica C++14. In precedenza era consentito utilizzare gli standard C++98\/03.\n
Nel garbage collector ZGC (Z Garbage Collector), operante in modalit\u00e0 passiva e che minimizza al massimo le latenze dovute alla raccolta dei rifiuti, \u00e8 stata aggiunta la possibilit\u00e0 di elaborazione parallela degli stack dei thread senza sospendere l'esecuzione dei thread dell'applicazione. In ZGC rimangono ora solo le operazioni che richiedono una sospensione, che hanno ritardi costanti, solitamente non superiori a poche centinaia di microsecondi.\n
Nelle classi SocketChannel, ServerSocketChannel e java.nio.channels \u00e8 stata aggiunta la supporto per i socket Unix (AF_UNIX).\n
Realizzato un porting per la distribuzione Linux Alpine con la libreria C standard musl, popolare in ambienti per container, microservizi, cloud e sistemi embedded. Il porting proposto in tali ambienti consente di eseguire programmi Java come normali applicazioni. Inoltre, utilizzando jlink si possono rimuovere tutti i moduli non utilizzati e creare un ambiente minimo sufficiente per eseguire l'applicazione, permettendo di generare immagini compatte specifiche per applicazioni.\n
\u00c8 stato realizzato un meccanismo Elastic Metaspace, che ottimizza le operazioni di allocazione e restituzione della memoria occupata dai metadati delle classi (metaspace) nella JVM HotSpot. L'uso di Elastic Metaspace riduce la frammentazione della memoria, diminuisce le spese generali nel caricatore di classi e influisce positivamente sulle prestazioni delle applicazioni server a lungo termine grazie a un pi\u00f9 rapido ritorno alla sistema operativo della memoria occupata dai metadati delle classi non utilizzati. Per scegliere la modalit\u00e0 di rilascio della memoria dopo il caricamento delle classi, \u00e8 stata proposta l'opzione «-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)».\n
Aggiunto il port JDK per sistemi Windows che operano su hardware con processori basati sull'architettura AArch64.\n
Proposto un terzo tentativo preliminare dell'API Foreign-Memory Access, che consente alle applicazioni Java di accedere in modo sicuro ed efficiente alle aree di memoria al di fuori dell'heap Java, manipolando le nuove astrazioni MemorySegment, MemoryAddress e MemoryLayout.\n
Implementato un API sperimentale Foreign Linker, che offre accesso da Java a codice nativo. Insieme all'API Foreign-Memory, la nuova interfaccia semplifica notevolmente la creazione di wrapper per comuni librerie condivise.\n
Aggiunto lo strumento jpackage, che consente di creare pacchetti per applicazioni Java autonome. Lo strumento si basa su javapackager di JavaFX e permette di generare pacchetti in formati nativi per diverse piattaforme (msi ed exe per Windows, pkg e dmg per macOS, deb e rpm per Linux). I pacchetti includono tutte le dipendenze necessarie.\n
Attivata per impostazione predefinita la rigorosa incapsulazione di tutti gli elementi interni del JDK, tranne le API critiche, come sun.misc.Unsafe. Il valore dell'opzione «—illegal-access» \u00e8 ora impostato per impostazione predefinita a «deny» invece che a «permit», il che porter\u00e0 al blocco dei tentativi di accesso da codice alla maggior parte delle classi, metodi e campi interni. Per aggirare questa limitazione, utilizzare l'opzione «—illegal-access=permit».\n
Stabilizzata l'implementazione del matching con il pattern nell'operatore «instanceof», che consente di definire immediatamente una variabile locale per accedere al valore verificato. Ad esempio, \u00e8 possibile scrivere subito «if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}» senza definire esplicitamente «String s = (String) obj». Prima: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Ora \u00e8 possibile evitare di definire «Group group = (Group) obj»: if (obj instanceof Group group) { var entries = group.getEntries(); }\n
La realizzazione della parola chiave \u00abrecord\u00bb \u00e8 stata stabilizzata, fornendo una forma compatta per definire classi, che consente di evitare la definizione esplicita di vari metodi a basso livello, come equals(), hashCode() e toString(), nei casi in cui i dati vengono salvati solo nei campi, il cui comportamento non cambia. Quando una classe utilizza implementazioni di tipo dei metodi equals(), hashCode() e toString(), \u00e8 possibile evitare la loro definizione esplicita: public record BankTransaction(LocalDate date, double amount, String description) {}\n
Questa dichiarazione porter\u00e0 all'aggiunta automatica delle implementazioni dei metodi equals(), hashCode() e toString() oltre al costruttore e ai metodi che controllano la modifica dei dati (getter). <\/p>\n
\u00c8 stata proposta una seconda versione preliminare delle classi e interfacce sigillate (\u00absealed\u00bb), che non possono essere utilizzate da altre classi e interfacce per ereditare, estendere o sovrascrivere implementazioni. Le classi sigillate offrono anche un modo pi\u00f9 dichiarativo per limitare l'uso della superclasse, rispetto ai modificatori di accesso, basato sull'elenco esplicito delle sottoclassi consentite per l'estensione. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {...} <\/ul>\n