Oracle ha annunciato la disponibilità di Java 17, nuova versione del linguaggio di programmazione e della piattaforma di sviluppo numero uno al mondo. Java 17 presenta migliaia di aggiornamenti in ottica di performance, stabilità e sicurezza e 14 JEPS (JDK Enhancement Proposal): innovazioni che migliorano ulteriormente Java per aiutare gli sviluppatori a essere più produttivi.
Una delle importanti funzionalità JVM aggiunte in questa versione è il supporto per macOS su AArch64architecture con JEP 391, aggiungendo così il supporto per la nuova linea di CPU (M1) rilasciata da Apple con i propri computer lo scorso anno. Questa non è esattamente una novità, poiché alcuni fornitori hanno già rilasciato versioni del JDK che supportano questa architettura, persino riportando il supporto fino a Java 8. Tuttavia, il timbro ufficiale di approvazione è ancora importante per la futura manutenzione e supporto per la piattaforma. Per confronto, il supporto per la piattaforma Linux/AArch64 è stato aggiunto in Java 9 e per Windows/AArch64 in Java 16.
La funzione Sealed Classes ha terminato la sua fase di anteprima ed è ora una parte standard del linguaggio e della piattaforma a partire da Java 17, come definito in JEP 409. Sealed Classes consente a uno sviluppatore di dichiarare esplicitamente i sottotipi consentiti di un tipo, impedendo così altri di estenderlo o implementarlo involontariamente.
Java 17 offre anche una nuova pipeline di rendering (JEP 382) per le applicazioni AWT/Swing in esecuzione su macOS, utilizzando l'API Metal di Apple anziché OpenGL, nonché nuove API e miglioramenti per la generazione di numeri casuali (JEP 356).
Java 17 porta anche diverse deprecazioni, rimozioni e restrizioni aggiunte.
Una rimozione è il completamento dell'incapsulamento di JDK Internals (JEP 403). Questo è stato introdotto per la prima volta in Java 9 e darebbe avvisi di runtime se un utente tentasse di utilizzare la reflection o se volesse aggirare le normali restrizioni per l'utilizzo di API interne. È stato inoltre aggiunto un argomento della riga di comando per controllare questo comportamento.
Da Java 9, sono state introdotte varie API per fornire un modo standardizzato di fare le cose più comuni per cui le persone utilizzerebbero queste API interne. In Java 16 l'impostazione predefinita è stata modificata dal dare un avviso al negare l'accesso lanciando un'eccezione, ma conservando ancora l'argomento della riga di comando per modificare il comportamento.
Ora con Java 17, l'argomento della riga di comando viene rimosso e quindi anche la possibilità di disabilitare questa restrizione, il che significa che tutti gli accessi non autorizzati a quelle API interne sono ora fortemente incapsulati.
Un'altra "rimozione" è il ripristino della semantica a virgola mobile sempre rigorosa (JEP 306). Java 1.2 ha introdotto modifiche alla semantica in virgola mobile predefinita in Java, consentendo in sostanza alla JVM di scambiare un po' di precisione in virgola mobile per le prestazioni. Per i metodi e le classi in cui era necessario applicare la semantica, è stata introdotta una parola chiave strictfp. Da allora, sono stati aggiunti nuovi set di istruzioni alle CPU, facendo funzionare la semantica a virgola mobile rigida senza sovraccarico eccessivo, quindi la motivazione per avere una semantica predefinita e rigorosa non esiste più.
La parola chiave strictfp è ancora presente ma non ha alcun effetto e produce un avviso in fase di compilazione.
Compilazione anticipata (AOT)
Java 9 ha introdotto la compilazione anticipata (AOT) come funzionalità sperimentale utilizzando il compilatore Graal, un compilatore JIT scritto in Java. Java 10 ha reso il compilatore Graal utilizzabile come compilatore JIT in OpenJDK utilizzando l'interfaccia JVMCI. Da allora, il compilatore Graal ha subito enormi miglioramenti e ora è anche la propria JVM sotto forma di GraalVM. I vantaggi di averlo parte di OpenJDK sono diminuiti e con JEP 410 è stato rimosso.
RMI Activation
La funzione RMI Activation è stata rimossa con JEP 407, dopo essere stata resa facoltativa in Java 8 e infine deprecata e contrassegnata per la rimozione in Java 15. La RMI Activation ha consentito di attivare gli oggetti distribuiti su richiesta tramite RMI, ma ha visto scarso utilizzo e oggi esistono alternative migliori.
Applet API
L' applet API è stata finalmente contrassegnata per la rimozione con JEP 398, in precedenza era deprecata in Java 9. L'API dell'applet ha fornito un modo per incorporare i controlli Java AWT/Swing in una pagina Web nel browser, ma nessun browser moderno oggi lo supporta, quindi Applets è stato essenzialmente irrilevante negli ultimi dieci anni o più.
Manager della sicurezza
La più grande deprecazione è senza dubbio quella del Security Manager (JEP 411). Security Manager esiste da Java 1.0 ed era generalmente inteso a limitare ciò che Java potesse fare sulla macchina locale, come limitare l'accesso a file, rete, determinate API, ecc..
La deprecazione di Security Manager è iniziata in Java 12, dove è stato aggiunto un argomento della riga di comando che ne impedisce l'uso e, da Java 18 in avanti, tale argomento della riga di comando verrà impostato automaticamente per impedire l'impostazione di un Security Manager in fase di esecuzione. La modifica in Java 17 significa che un avviso di runtime verrà prodotto dalla JVM quando si tenta di impostare un Security Manager, dalla riga di comando o dinamicamente in fase di esecuzione.
Oracle JDK 17 e le future release JDK saranno fornite con una licenza ad uso gratuito fino all’intero anno successivo alla prossima release LTS. Oracle continuerà anche a offrire rilasci Oracle OpenJDK sotto la licenza open source General Public License (GPL), come fa sin dal 2017.
Tutti i dettagli sono disponibili sulla pagina ufficiale.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
