Java JDK 11: tutte le nuove funzionalità ora disponibili

Java Development Kit (JDK) 11 è ora generalmente disponibile e pronto per l'uso in produzione, apportando miglioramenti alla produttività e un'API client HTTP che implementa HTTP / 2.

La versione 11 di Java Standard Edition (SE) ha 16 principali modifiche alle funzionalità. Java 11 perde anche alcune funzionalità a causa della rimozione dei moduli CORBA e Java EE (recentemente ribattezzato Jakarta EE), nonché della rimozione di JavaFX, che è ora disponibile come tecnologia autonoma.

In Java 11, Oracle ha biforcato il repository della linea principale, jdk / jdk, al repository di stabilizzazione jdk / jdk11. Le modifiche inviate a jdk / jdk o jdk / client sono ora contrassegnate per JDK 12. Il repository di stabilizzazione può accettare correzioni di bug selezionate e, se approvato, miglioramenti tardivi secondo il processo di rilascio di JDK.

L'ultima versione dell'implementazione di Oracle dello standard Java è una versione Long Term Support (LTS), che avrà il supporto commerciale di Oracle per almeno otto anni. Correzioni di bug e aggiornamenti di sicurezza saranno offerti fino al 2026. Le nuove versioni di LTS sono previste ogni tre anni, con JDK 17, previsto nel 2021, previsto per essere il prossimo rilascio di LTS. Le versioni provvisorie verranno ogni sei mesi.

Dove scaricare JDK 11

È possibile scaricare JDK 11 da Oracle Technology Network.

Nuove funzionalità in Java 11 JDK

JDK 11 ha 16 nuove funzionalità:

  • Miglioramento degli intrinseci di Aarch64, con l'implementazione di nuovi intrinseci per le  lang.Mathfunzioni sin, cos e log, sui processori Aarch64. Questa proposta enfatizza modelli di codice specifici dell'architettura della CPU specializzati che migliorano le prestazioni dell'applicazione e del benchmark.
  • Il controllo degli accessi basato su Nest introduce i nidi, un contesto di controllo degli accessi che si allinea con la nozione di tipi annidati nel linguaggio Java. I nidi consentono alle classi che fanno parte logicamente della stessa entità di codice ma sono compilate in file di classe distinti per accedere ai membri privati ​​l'uno dell'altro senza bisogno di compilatori per inserire metodi bridge che ampliano l'accessibilità.
  • Transport Layer Security (TLS) 1.3, in cui questa revisione del protocollo TLS verrà inserita in JDK 11, offrendo vantaggi significativi in ​​termini di sicurezza e prestazioni. Non c'è alcun obiettivo, tuttavia, per supportare tutte le funzionalità di TLS 1.3. Per ridurre al minimo i rischi di incompatibilità, TLS 1.3 implementerà la modalità di compatibilità con le versioni precedenti per impostazione predefinita. Le applicazioni possono attivare o disattivare questa modalità come desiderato.
  • Deprecazione del motore JavaScript Nashorn, insieme allo strumento JJS, con l'intento di rimuoverli in futuro. Oracle ha trovato Nashorn difficile da mantenere, dato il rapido ritmo con cui i costrutti del linguaggio ECMAScript e le API sono stati adattati e modificati.
  • HTTP Client (Standard), che standardizza il client API HTTP incubato introdotto in JDK 9 e aggiornato in JDK 10. L'API offre semantica di richiesta e risposta non bloccante CompleteableFutures, che può essere collegata per attivare azioni dipendenti. L'implementazione, ora asincrona, è stata quasi completamente riscritta, dopo l'incubazione nei JDK 9 e 10. Il concetto di RX Flow è stato inserito nell'implementazione, eliminando molti concetti personalizzati necessari per supportare HTTP / 2. Il flusso di dati ora può essere tracciato più facilmente, dagli editori di richieste a livello utente e dagli editori di risposte al socket sottostante. Ciò riduce la complessità e massimizza la possibilità di riutilizzo tra HTTP / 1 e HTTP / 2.
  • Il Garbage Collector Epsilon, fatturato come un collector "no-op", gestirà l'allocazione della memoria senza implementare alcun meccanismo di recupero della memoria effettivo. I casi d'uso di Epsilon includono test per prestazioni, pressione della memoria e interfaccia della macchina virtuale. Potrebbe anche essere utilizzato per lavori di breve durata.
  • Una sintassi di variabile locale per i parametri lambda dovrebbe allineare la sintassi di una dichiarazione di parametro formale in un'espressione tipizzata in modo implicito con la sintassi di una dichiarazione di variabile locale. Ciò consentirebbe var di essere utilizzato quando si dichiarano parametri formali di espressioni lambda tipizzate in modo implicito.
  • Il formato di file di classe Java verrà esteso per supportare una nuova forma piscina costante, CONSTANT_Dynamic. L'obiettivo è ridurre i costi e le interruzioni dello sviluppo di nuove forme di vincoli materializzabili di file di classe.
  • L'accordo chiave con la crittografia Curve25519 e Curve448 dovrebbe essere più efficiente e sicuro rispetto allo schema Diffie-Hellman a curva ellittica esistente. Le due curve ellittiche, Curve25510 e Curve448, si prestano a un'implementazione a tempo costante e a una moltiplicazione scalare priva di eccezioni che è più resistente a una serie di attacchi di canale laterale, inclusi attacchi di temporizzazione e cache, secondo IETF. Gli obiettivi della proposta includono un'API e l'implementazione dello schema dell'accordo chiave, nonché lo sviluppo di un'implementazione completamente Java indipendente dalla piattaforma. Esiste un rischio, tuttavia, nella complessità e sottigliezza dell'implementazione aritmetica modulare presente come parte della proposta.
  • Flight Recorder fornirebbe un framework di raccolta dati a basso overhead per la risoluzione dei problemi sia delle applicazioni Java che della JVM HotSpot. Flight Recorder è stata una funzionalità del JDK commerciale di Oracle, ma avrebbe spostato il suo codice sorgente in un repository aperto per rendere la funzionalità generalmente disponibile. Iclouded sarebbero le API per produrre e consumare dati come eventi, fornendo un meccanismo di buffer e un formato di dati binario e consentendo la configurazione e il filtraggio degli eventi. La proposta richiede anche di fornire eventi per le librerie OS, HotSpot e JDK.
  • Aggiornamento delle API della piattaforma per supportare Unicode versione 10.0, mantenendo così Java aggiornato. Il supporto è previsto nelle seguenti classi:
    • Charactere Stringnella langconfezione
    • NumericShapernella awt.fontconfezione
    • Bidi, BreakIteratore Normalizernel textpacchetto
  • Implementazione degli algoritmi crittografici ChaCha20 e Poly1305. ChaCha2020 è un cifrario a flusso relativamente nuovo che può sostituire il vecchio e non sicuro cifrario a flusso R4. ChaCha20 sarebbe accoppiato con l'autenticatore Poly1305. Verrebbero fornite le implementazioni di cifratura ChaCha20 e ChaCha20-Poly1305, con gli algoritmi implementati nel provider SunJCE (Java Cryptography Extension), utilizzando l' crypto.CipherSpiAPI.
  • Miglioramento del programma di avvio Java per eseguire un programma fornito come un singolo file di codice sorgente Java, in modo che questi programmi possano essere eseguiti direttamente dall'origine. I programmi a file singolo sono comuni quando si scrivono piccole utilità o per gli sviluppatori nelle prime fasi di apprendimento di Java. Inoltre, un singolo file di origine potrebbe essere compilato in più file di classe, il che aggiunge un sovraccarico di imballaggio. In questi contesti, dover compilare un programma prima di eseguirlo è solo un passaggio non necessario basato sulla tradizione.
  • Profilazione dell'heap a basso overhead, che fornisce un modo per campionare le allocazioni di heap Java, accessibile tramite JVM Tool Interface. L'obiettivo di questo sforzo è ottenere informazioni su queste allocazioni in un modo con un sovraccarico ridotto, a cui è possibile accedere tramite un'interfaccia programmatica e in grado di campionare tutte le allocazioni. Anche l'indipendenza dall'implementazione e la fornitura di dati sui cumuli vivi e morti sono obiettivi. Una cattiva gestione dell'heap può portare all'esaurimento dell'heap e alla raccolta dei rifiuti. La maggior parte degli strumenti che risolvono questo problema non dispone del sito di chiamata per allocazioni particolari, informazioni che possono essere fondamentali per il debug dei problemi di memoria.
  • Deprecazione degli strumenti Pack200 e Unpack200 e dell'API Pack200 in util.jar. Pack200 è uno schema di compressione per i file .jar, inteso a ridurre i requisiti di disco e larghezza di banda per la creazione di pacchetti, la trasmissione e la consegna delle applicazioni. I costi di manutenzione e il basso utilizzo non giustificano la loro conservazione, affermano i responsabili del progetto.
  • Z Garbage Collector (ZGC), un garbage collector sperimentale a bassa latenza, per gestire heap che vanno da heap relativamente piccoli a heap molto grandi con dimensioni di molti terabyte. Utilizzando ZGC, i tempi di pausa non dovrebbero superare i 10 ms e non dovrebbe esserci una riduzione del throughput dell'applicazione superiore al 15% rispetto all'utilizzo del collector G1. ZGC pone anche le basi per funzionalità e ottimizzazioni future. Linux / x64 sarà la prima piattaforma a ottenere il supporto ZGC.

Cosa è stato rimosso da Java JDK 11

I moduli Java EE EE e CORBA sono stati deprecati in Java SE 9, con l'intento di rimuoverli in una versione successiva, ovvero JDK 11.

Java SE 6, rilasciato nel dicembre 2006, includeva uno stack completo di servizi Web per la comodità degli sviluppatori, comprese quattro tecnologie costruite per la piattaforma Java EE: JAX-WS (Java API for XML-based Web Services, JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework) e Common Annotations for Java. Nel tempo, le versioni di Java EE si sono evolute, portando a difficoltà in Java SE, come l'inclusione di tecnologie irrilevanti per Java SE e una manutenzione più difficile tra i due Java Con le versioni standalone delle tecnologie Java EE disponibili da siti di terze parti, Oracle afferma che non è più necessario averle in Java SE o in JDK.

Tuttavia, alcune applicazioni non verranno compilate o eseguite se si basano sul supporto pronto all'uso in JDK per API e strumenti Java EE. Durante la migrazione di JDK 6, 7 o 8 a una versione successiva si verificavano incompatibilità binarie e di origine. Oracle afferma che gli sviluppatori interessati da questi rischi possono invece distribuire versioni alternative delle tecnologie Java EE.

CORBA risale agli anni '90 e Oracle afferma che oggi non vi è alcun interesse significativo nello sviluppo di moderne applicazioni Java con CORBA. E i costi per mantenere il supporto CORBA superano i vantaggi rimanenti.

Ma la rimozione di CORBA rischia di avere implementazioni CORBA che non verranno eseguite se includono solo un sottoinsieme di API CORBA e si aspettano che JDK fornisca il resto. Non esiste una versione CORBA di terze parti e non è chiaro se una terza parte possa subentrare nella manutenzione dell'API CORBA.

JavaFX viene rimosso, quindi non è legato al programma di aggiornamento biennale di Java JDK.