{"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\/novosti-interneta\/vypusk-java-se-16","title":{"rendered":"Versione 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), la cui implementazione di riferimento utilizza il progetto open source OpenJDK. In Java SE 16 \u00e8 mantenuta la retrocompatibilit\u00e0 con le versioni precedenti della piattaforma Java; tutti i progetti Java precedentemente scritti funzioneranno senza modifiche con l'esecuzione sotto la nuova versione. Le build 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 come una release con supporto standard, con aggiornamenti previsti fino al prossimo rilascio. Per una versione a lungo termine (LTS), si consiglia di utilizzare Java SE 11, con aggiornamenti rilasciati fino al 2026. Il prossimo rilascio LTS \u00e8 programmato per settembre 2021. Ricordiamo che a partire dal rilascio di Java 10, il progetto ha adottato un nuovo processo di sviluppo, caratterizzato da cicli di rilascio pi\u00f9 brevi. Ora, le nuove funzionalit\u00e0 vengono sviluppate in un master branch continuamente aggiornato, dove vengono incluse le modifiche gi\u00e0 pronte, e da cui si diramano branch ogni sei mesi per stabilizzare i nuovi rilasci. <\/p>\n
Nella preparazione del nuovo rilascio, lo sviluppo \u00e8 stato trasferito dal sistema di controllo 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 di archiviazione, consenta l'accesso alle modifiche per l'intera storia del progetto, migliori il supporto per la revisione del codice e consenta l'uso delle API per l'automazione dei flussi di lavoro. Inoltre, l'uso di Git e GitHub rende il progetto pi\u00f9 attraente per i neofiti e per gli sviluppatori abituati a Git. <\/p>\n
Tra le novit\u00e0 di Java 16 possiamo evidenziare: <\/p>\n
\n
\u00c8 stato aggiunto un modulo sperimentale jdk.incubator.vector con un'implementazione dell'API Vector, che fornisce funzioni per i calcoli vettoriali eseguiti utilizzando le istruzioni vettoriali dei processori x86_64 e AArch64, permettendo di applicare simultaneamente operazioni a pi\u00f9 valori (SIMD). A differenza delle capacit\u00e0 di auto-vectorizzazione per le operazioni scalari fornite dal compilatore JIT HotSpot, la nuova API consente di gestire esplicitamente la vettorizzazione per l'elaborazione parallela dei dati.\n
Nel codice JDK e VM HotSpot, scritto in C++, \u00e8 consentito utilizzare le funzionalit\u00e0 introdotte dalla specifica C++14. In precedenza, era consentito l'uso degli standard C++98\/03.\n
Nel garbage collector ZGC (Z Garbage Collector), che opera in modalit\u00e0 passiva e riduce al minimo i ritardi causati dalla raccolta dei rifiuti, \u00e8 stata aggiunta la funzionalit\u00e0 di elaborazione parallela degli stack dei thread senza sospendere l'esecuzione dei thread dell'applicazione. In ZGC rimangono ora solo i passaggi che richiedono la sospensione del lavoro, i quali comportano ritardi costanti, solitamente non superiori a poche centinaia di microsecondi.\n
Nelle classi SocketChannel, ServerSocketChannel e java.nio.channels \u00e8 stata aggiunta il supporto per i socket Unix (AF_UNIX).\n
\u00c8 stato implementato un porting per la distribuzione Linux Alpine con la libreria C standard musl, popolare negli ambienti per container, microservizi, sistemi cloud e embedded. Il porting proposto in tali contesti consente di eseguire programmi Java come normali applicazioni. Inoltre, grazie a jlink, \u00e8 possibile rimuovere tutti i moduli non utilizzati e creare un ambiente minimo sufficiente per eseguire l'applicazione, permettendo di generare immagini compatte specifiche per applicazioni particolari.\n
\u00c8 stato implementato il 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 il sovraccarico nel caricatore di classi e migliora le prestazioni delle applicazioni server a lungo termine grazie a un pi\u00f9 rapido rilascio della memoria occupata dai metadati delle classi non utilizzati all'operativo di sistema. Per scegliere la modalit\u00e0 di rilascio della memoria dopo lo scarico delle classi, \u00e8 stata proposta l'opzione «-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)».\n
Aggiunto il porto JDK per i sistemi Windows che operano su hardware con processori basati sull'architettura AArch64.\n
Proposto un terzo prototipo dell'API Foreign-Memory Access, che consente alle applicazioni Java di accedere in modo sicuro ed efficiente a aree di memoria al di fuori dell'heap Java, manipolando le nuove astrazioni MemorySegment, MemoryAddress e MemoryLayout.\n
Realizzato un'API sperimentale Foreign Linker, che fornisce accesso da Java a codice nativo. Insieme all'API Foreign-Memory, questa nuova interfaccia semplifica notevolmente la creazione di wrapper per librerie condivise comuni.\n
Aggiunta l'utilit\u00e0 jpackage, che consente di creare pacchetti per applicazioni Java autoconclusive. L'utilit\u00e0 si basa su javapackager di JavaFX e permette di generare pacchetti in formati nativi per diverse piattaforme (msi e exe per Windows, pkg e dmg per macOS, deb e rpm per Linux). I pacchetti includono tutte le dipendenze necessarie.\n
\u00c8 attivata di default la rigorosa incapsulazione di tutti gli elementi interni del JDK, ad eccezione delle API critiche, come sun.misc.Unsafe. Il valore dell'opzione «—illegal-access» \u00e8 ora impostato di default su «deny» invece di «permit», il che porter\u00e0 a bloccare i tentativi di accesso dal codice alla maggior parte delle classi, metodi e campi interni. Per aggirare il limite, si deve usare l'opzione «—illegal-access=permit».\n
\u00c8 stata stabilizzata l'implementazione del confronto con il modello nell'operatore \u00abinstanceof\u00bb, che consente di definire immediatamente una variabile locale per accedere al valore verificato. Ad esempio, \u00e8 possibile scrivere subito \u00abif (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}\u00bb senza dover esplicitamente definire \u00abString s = (String) obj\u00bb. Prima: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Ora si pu\u00f2 fare a meno della definizione \u00abGroup group = (Group) obj\u00bb: if (obj instanceof Group group) { var entries = group.getEntries(); }\n
\u00c8 stata stabilizzata l'implementazione della parola chiave \u00abrecord\u00bb, che fornisce una forma compatta per definire classi, permettendo di evitare la definizione esplicita di vari diversi metodi di basso livello, come equals(), hashCode() e toString(), nei casi in cui i dati vengono memorizzati solo nei campi, il cui comportamento non cambia. Quando in una classe vengono utilizzate implementazioni di tipo dei metodi equals(), hashCode() e toString(), \u00e8 possibile fare a meno della 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 bozza preliminare di classi e interfacce sigillate («sealed»), che non possono essere utilizzate da altre classi e interfacce per l'ereditariet\u00e0, l'estensione o la ridefinizione dell'implementazione. Le classi sigillate offrono anche un modo pi\u00f9 dichiarativo di limitare l'uso della superclasse, rispetto ai modificatori di accesso, basato su un'esplicita enumerazione delle sottoclassi autorizzate all'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