Udgivelsen af Java SE 15

Efter seks måneders udvikling har Oracle udgivet platformen Java SE 15 (Java Platform, Standard Edition 15), hvis referenceimplementering er det åbne projekt OpenJDK. Java SE 15 bevarer bagudkompatibiliteten med tidligere udgaver af Java-platformen, så alle tidligere skrevne Java-projekter vil fungere uden ændringer, når de kører på den nye version. Installationspakkerne til Java SE 15 (JDK, JRE og Server JRE) forberedes til Linux (x86_64), Windows og macOS. Den referenceimplementering, der er udviklet inden for projektet OpenJDK, Java 15 er helt åbne under GPLv2-licensen med undtagelser for GNU ClassPath, der tillader dynamisk binding til kommercielle produkter.

Java SE 15 er klassificeret som en version med standard supportperiode, hvor opdateringer vil blive udgivet indtil den næste version. Java SE 11 bør anvendes som en version med langvarig support (LTS), og opdateringer til den vil blive udgivet indtil 2026. Den tidligere LTS-version, Java 8, vil blive støttet indtil december 2020. Næste LTS-udgivelse er planlagt til september 2021. Det skal bemærkes, at siden Java 10-projektet er overgået til en ny udviklingsproces, der indebærer en kortere cyklus for at producere nye udgivelser. Ny funktionalitet udvikles nu i en konstant opdateret master-branch, hvorfærdige ændringer integreres, og hver sjette måned oprettes der branches til stabilisering af de nye udgivelser.

Af nyheder Java 15 you can markere:

  • Indbygget understøttelse af algoritmen til at generere digitale signaturer EdDSA (Edwards-Curve Digital Signature Algorithm RFC 8032). Den foreslåede EdDSA-implementering er uafhængig af hardware-platforme, er beskyttet mod angreb gennem sidekanaler (sikrer konstant tid for alle beregninger), og dens ydeevne overgår eksisterende ECDSA-implementeringer skrevet i C ved samme sikkerhedsniveau. For eksempel viser EdDSA ved brug af en elliptisk kurve med en 126-bit nøgle ydeevne, der er sammenlignelig med ECDSA med den elliptiske kurve secp256r1 og en 128-bit nøgle.
  • Tilføjet eksperimentel support til sealed klasser og interfaces, som ikke kan bruges af andre klasser og interfaces til arve, udvide eller overskrive implementeringen. Sealed klasser tilbyder også en mere deklarativ måde at begrænse brugen af superklassen på, end adgangsmodifikatorer, baseret på en eksplicit opregning af subklasser, der er tilladt til udvidelse.

    package com.example.geometry;

    public sealed class Shape
    permits com.example.polar.Circle,
    com.example.quad.Rectangle,
    com.example.quad.simple.Square {…}

  • Tilføjet support til skjulte klasser, som ikke kan bruges direkte af bytekode fra andre klasser. Det primære formål med skjulte klasser er at blive brugt i rammer, der dynamisk genererer klasser under kørsel og bruger dem indirekte gennem refleksion.Sådanne klasser har normalt en begrænset livscyklus, så det er ikke berettiget at opretholde dem til adgang fra statisk genererede klasser, og det vil kun føre til øget hukommelsesforbrug. Skjulte klasser tillader også at undgå brugen af den ikke-standardiserede API sun.misc.Unsafe::defineAnonymousClass, som er planlagt til at blive fjernet i fremtiden.
  • Z Garbage Collector (ZGC) er stabiliseret og anerkendt som klar til bred anvendelse. ZGC arbejder i passiv tilstand, så langt det er muligt, og minimerer forsinkelser forårsaget af garbage collection (pause-tiden ved brug af ZGC overskrider ikke 10 ms) og kan arbejde med både små og enorme heap-størrelser, fra flere hundrede megabyte til mange terabyte.
  • Er stabiliseret og anerkendt som klar til generel brug
    garbage collector Shenandoah, som arbejder med minimal pausetid (Low-Pause-Time Garbage Collector). Shenandoah er udviklet af Red Hat og er bemærkelsesværdig for brugen af en algoritme, der reducerer stop-tider under garbage collection ved at udføre oprydning parallelt med kørsel af Java-applikationer. Den tid, som garbage collector genererer som forsinkelse, er forudsigelig og afhænger ikke af størrelsen af heap, dvs. forsinkelser for heaps på 200 MB og 200 GB vil være identiske (overskrider 50 ms og ligger typisk omkring 10 ms);
  • Støtten til tekstblokke er stabiliseret og tilføjet til sproget. tekstblokke — nye former for strenglitteraler, der gør det muligt at inkludere flere linjer tekstdata i kildekoden uden at anvende karakterescapement og bevare den oprindelige tekstformatering i blokken. Blokken indrammes med tre doble citationstegn.

    For eksempel i stedet for koden

    String html = "" +
    "\n\t" + "" +
    "\n\t\t" + "

    Java 15 er her!

    " +
    "\n\t" + "" +
    "\n" + "";

    kan man angive:

    String html = """
    <HTML>
    <BODY>

    Java 15
    er her!


    </BODY>
    """;

  • Omarbejdet API Legacy DatagramSocket. De ældre implementeringer af java.net.DatagramSocket og java.net.MulticastSocket er blevet erstattet med en moderne implementering, der er lettere at debugge og vedligeholde, samt kompatibel med virtuelle tråde, der udvikles under projektet Loom. For at undgå mulig inkompatibilitet med eksisterende kode er den gamle implementering ikke fjernet og kan aktiveres ved hjælp af indstillingen jdk.net.usePlainDatagramSocketImpl.
  • En anden eksperimentel implementering er foreslået til mønster-matchning i "instanceof"-operatoren, som gør det muligt straks at bestemme en lokal variabel for at få adgang til den kontrollerede værdi. For eksempel kan man straks skrive "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" uden at skulle definere "String s = (String) obj" eksplicit.

    Tidligere:

    if (obj instanceof Group) {
    Group group = (Group) obj;
    var entries = group.getEntries();
    }

    Nu kan man undvære definitionen "Group group = (Group) obj":

    if (obj instanceof Group group) {
    var entries = group.getEntries();
    }

  • Forslaget den anden eksperimentale implementering af nøgleordet "record", der giver en kompakt form for at definere klasser, som gør det muligt at undgå eksplicitte definitioner af forskellige lavniveau-metoder, såsom equals(), hashCode() og toString(), i tilfælde hvor data kun gemmes i felterne, hvis opførsel ikke ændres. Når klassemetoderne equals(), hashCode() og toString() anvendes, kan man undvære deres eksplicitte definition:

    public record BankTransaction(LocalDate date,
    double beløb,
    String beskrivelse) {}

    Denne meddelelse vil automatisk føre til tilføjelse af implementeringerne af metoderne equals(), hashCode() og toString() samt konstruktøren og metoderne, der kontrollerer datamodifikation (getter).

  • En anden anden foreløbig version af API'en Foreign-Memory Access er blevet foreslået, hvilket gør det muligt for Java-applikationer sikkert og effektivt at få adgang til hukommelsesområder uden for Java-haugen ved at manipulere med de nye abstraktioner MemorySegment, MemoryAddress og MemoryLayout.
  • Understøttelsen af Den forældede optimeringsteknik Biased Locking, som blev anvendt i HotSpot JVM for at reducere overhead fra låsninger, er blevet erklæret forældet. Denne teknik har mistet relevans på systemer med atomære instruktioner, der leveres af moderne CPU'er, og er for omkostningstung at vedligeholde på grund af sin kompleksitet.
  • Erklæret forældet mekanisme RMI Activation, som vil blive fjernet i en af de kommende versioner. Det bemærkes, at RMI Activation er forældet, og blev omklassificeret som en mulighed allerede i Java 8 og næsten ikke anvendes i moderne praksis.
  • Fjernet JavaScript-motoren Nashorn, som blev erklæret forældet i Java SE 11.
  • Fjernet porte til Solaris OS og SPARC processorer (Solaris/SPARC, Solaris/x64 og Linux/SPARC). Fjernelse af de nævnte porte vil gøre det muligt for samfundet at fremskynde udviklingen af nye muligheder for OpenJDK uden at spilde tid på at opretholde funktioner, der er specifikke for Solaris og SPARC.

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster