Versione Java SE 15

Dopo sei mesi di sviluppo, Oracle rilasciato una piattaforma JavaSE 15 (Piattaforma Java, Standard Edition 15), il progetto open source OpenJDK viene utilizzato come implementazione di riferimento. Java SE 15 mantiene la compatibilità con le versioni precedenti della piattaforma Java; tutti i progetti Java scritti in precedenza funzioneranno senza modifiche una volta lanciati con la nuova versione. Build Java SE 15 pronte per l'installazione (JDK, JRE e Server JRE) preparato per Linux (x86_64), Windows e macOS. Implementazione di riferimento sviluppata dal progetto OpenJDK Java 15 è completamente open source sotto la licenza GPLv2, con eccezioni GNU ClassPath che consentono il collegamento dinamico con prodotti commerciali.

Java SE 15 è classificato come rilascio di supporto generale e continuerà a ricevere aggiornamenti fino al rilascio successivo. Il ramo Long Term Support (LTS) dovrebbe essere Java SE 11, che continuerà a ricevere aggiornamenti fino al 2026. Il precedente ramo LTS di Java 8 sarà supportato fino a dicembre 2020. La prossima versione LTS è prevista per settembre 2021. Ricordiamo che a partire dal rilascio di Java 10, il progetto è passato a un nuovo processo di sviluppo, implicando un ciclo più breve per la formazione di nuove versioni. Le nuove funzionalità sono ora sviluppate in un ramo principale costantemente aggiornato, che include modifiche già pronte e da cui si diramano i rami ogni sei mesi per stabilizzare le nuove versioni.

Di innovazioni Java 15 si può contrassegno:

  • Integrato supporto per l'algoritmo di creazione della firma digitale EdDSA (Edwards-Curve Digital Signature Algorithm). RFC 8032). L'implementazione EdDSA proposta non dipende dalle piattaforme hardware, è protetta dagli attacchi side-channel (è garantito un tempo costante di tutti i calcoli) ed è più veloce nelle prestazioni rispetto all'implementazione ECDSA esistente scritta in linguaggio C, con lo stesso livello di protezione. Ad esempio, EdDSA che utilizza una curva ellittica con una chiave a 126 bit mostra prestazioni simili a ECDSA con una curva ellittica secp256r1 e una chiave a 128 bit.
  • Aggiunto da supporto sperimentale per classi e interfacce sigillate, che non possono essere utilizzate da altre classi e interfacce per ereditare, estendere o sovrascrivere l'implementazione. Le classi sigillate forniscono anche un modo più dichiarativo per limitare l'uso di una superclasse rispetto ai modificatori di accesso, basato sull'elenco esplicito delle sottoclassi consentite per l'estensione.

    pacchetto com.example.geometry;

    classe pubblica sigillata Shape
    permette com.esempio.cerchio.polare,
    com.example.quad.Rectangle,
    com.example.quad.simple.Square {…}

  • Aggiunto da supporto per classi nascoste che non possono essere utilizzate direttamente dal bytecode di altre classi. Lo scopo principale delle classi nascoste è quello di essere utilizzate in framework che generano dinamicamente classi in fase di esecuzione e le utilizzano indirettamente, tramite отражение. Tali classi di solito hanno un ciclo di vita limitato, quindi mantenerle per l'accesso da classi generate staticamente non è giustificato e porterà solo a un maggiore consumo di memoria. Le classi nascoste eliminano inoltre la necessità dell'API non standard sun.misc.Unsafe::defineAnonymousClass, la cui rimozione è prevista in futuro.
  • Il garbage collector ZGC (Z Garbage Collector) è stato stabilizzato ed è riconosciuto come pronto per un uso diffuso. ZGC funziona in modalità passiva, riduce al minimo la latenza dovuta alla garbage collection (il tempo di stallo quando si utilizza ZGC non supera i 10 ms.) e può funzionare con heap sia piccoli che enormi, di dimensioni variabili da diverse centinaia di megabyte a molti terabyte.
  • Stabilizzato e trovato pronto per l'uso generale
    netturbino Shenandoah, lavorando con pause minime (Garbage Collector Low-Pause-Time). Shenandoah è stato sviluppato da Red Hat e si distingue per l'utilizzo di un algoritmo che riduce il tempo di stallo durante la garbage collection eseguendo la pulizia in parallelo con l'esecuzione delle applicazioni Java. La dimensione dei ritardi introdotti dal garbage collector è prevedibile e non dipende dalla dimensione dell'heap, ad es. per heap di 200 MB e 200 GB i ritardi saranno identici (non uscire oltre 50 ms e solitamente entro 10 ms);

  • Il supporto è stato stabilizzato e introdotto nella lingua blocchi di testo - una nuova forma di stringhe letterali che consente di includere dati di testo su più righe nel codice sorgente senza utilizzare l'escape dei caratteri e preservando la formattazione del testo originale nel blocco. Il blocco è racchiuso tra tre virgolette doppie.

    Ad esempio, invece di code

    StringaHTML = " »+
    "\n\t" + " »+
    "\n\t\t" + " \"Java 1 è qui!\" »+
    "\n\t" + " »+
    "\n" + " ";

    puoi specificare:

    Stringa html = """


    »Java 1\
    è qui!

    """;

  • Ridisegnato API DatagramSocket legacy. Le vecchie implementazioni di java.net.DatagramSocket e java.net.MulticastSocket sono state sostituite con un'implementazione moderna più semplice da eseguire il debug e la manutenzione ed è anche compatibile con i flussi virtuali sviluppati all'interno del progetto Telaio. In caso di possibile incompatibilità con il codice esistente, la vecchia implementazione non è stata rimossa e può essere abilitata utilizzando l'opzione jdk.net.usePlainDatagramSocketImpl.
  • Proposta la seconda implementazione sperimentale corrispondenza dei modelli nell'operatore “instanceof”, che consente di definire immediatamente una variabile locale per accedere al valore controllato. Ad esempio, puoi scrivere immediatamente "if (obj istanza di String s && s.length() > 5) {.. s.contains(..) ..}" senza definire esplicitamente "String s = (String) obj".

    Era:

    if (istanza oggetto del Gruppo) {
    Gruppo gruppo = (Gruppo) oggetto;
    var voci = group.getEntries();
    }

    Ora puoi fare a meno della definizione “Group group = (Group) obj”:

    if (istanza oggetto del gruppo Gruppo) {
    var voci = group.getEntries();
    }

  • Proposto seconda implementazione sperimentale della parola chiave "record", che fornisce un formato compatto per la definizione delle classi, consentendo di evitare di definire esplicitamente vari metodi di basso livello come equals(), hashCode() e toString() nei casi in cui i dati vengono archiviati solo in campi il cui comportamento non cambia. Quando una classe utilizza implementazioni standard dei metodi equals(), hashCode() e toString(), può fare a meno della loro definizione esplicita:

    record pubblico BankTransaction (data LocalDate,
    importo doppio
    Descrizione stringa) {}

    Questa dichiarazione aggiungerà automaticamente le implementazioni dei metodi equals(), hashCode() e toString() oltre ai metodi costruttore e getter.

  • Proposto una seconda anteprima dell'API Foreign-Memory Access, che consente alle applicazioni Java di accedere in modo sicuro ed efficiente alle regioni di memoria esterne all'heap Java manipolando le nuove astrazioni MemorySegment, MemoryAddress e MemoryLayout.
  • Disabilitato e ha deprecato la tecnica di ottimizzazione del blocco parziale utilizzata nella JVM HotSpot per ridurre il sovraccarico del blocco. Questa tecnica ha perso la sua rilevanza sui sistemi con istruzioni atomiche fornite dalle moderne CPU ed è troppo laboriosa da mantenere a causa della sua complessità.
  • Annunciato meccanismo obsoleto Attivazione RMI, che verrà rimosso in una versione futura. Va notato che l'attivazione RMI è obsoleta, relegata alla categoria di un'opzione in Java 8 e non viene quasi mai utilizzata nella pratica moderna.
  • RIMOSSO Motore JavaScript Nashorn, che è stato deprecato in Java SE 11.
  • RIMOSSO porte per il sistema operativo Solaris e i processori SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). La rimozione di queste porte consentirà alla comunità di accelerare lo sviluppo di nuove funzionalità OpenJDK senza perdere tempo nel mantenimento delle funzionalità specifiche di Solaris e SPARC.

Fonte: opennet.ru

Aggiungi un commento