Java >> Java tutorial >  >> Tag >> new

Nye funktioner i Java 17

1. Oversigt

I denne vejledning vil vi tale om nyhederne relateret til den nye version af Java-økosystemet, Java SE 17, inklusive de nye funktioner og ændringerne i dets udgivelsesproces, LTS-understøttelse og licenser.

2. Liste over JEP'er

Lad os først tale om, hvad der kan påvirke det daglige arbejde i Java-udvikleres liv.

2.1. Gendan Always-Strict Floating Point Semantics (JEP 306)

Denne JEP er hovedsageligt til videnskabelige applikationer, og den gør operationer med flydende komma konsekvent strenge. Standardoperationerne med flydende komma er strenge eller strictfp , som begge garanterer de samme resultater fra floating-point-beregningerne på hver platform.

Før Java 1.2, strictfp adfærd var også standard. Men på grund af hardwareproblemer ændrede arkitekterne sig, og søgeordet strictfp var nødvendigt for at genaktivere en sådan adfærd. Så der er ingen grund til at bruge dette søgeord længere.

2.2. Forbedrede pseudo-tilfældige talgeneratorer (JEP 356)

Også relateret til mere specielle use cases, JEP 356 giver nye grænseflader og implementeringer til Pseudo-Random Number Generators (PRNG).

Så det er nemmere at bruge forskellige algoritmer i flæng, og det giver også bedre understøttelse af stream-baseret programmering:

public IntStream getPseudoInts(String algorithm, int streamSize) {
    // returns an IntStream with size @streamSize of random numbers generated using the @algorithm
    // where the lower bound is 0 and the upper is 100 (exclusive)
    return RandomGeneratorFactory.of(algorithm)
            .create()
            .ints(streamSize, 0,100);
}

Ældre tilfældige klasser, såsom java.util.Random , SplittableRandom og SecureRandom Udvid nu den nye RandomGenerator grænseflade.

2.3. Ny macOS Rendering Pipeline (JEP 382)

Denne JEP implementerer en intern Java 2D-gengivelsespipeline til macOS, da Apple har udfaset OpenGL API (i macOS 10.14), der bruges internt i Swing GUI. Den nye implementering bruger Apple Metal API, og bortset fra den interne motor var der ingen ændringer til de eksisterende API'er.

2.4. macOS/AArch64 Port (JEP 391)

Apple annoncerede en langsigtet plan om at skifte sin computerlinje fra X64 til AArch64. Denne JEP porterer JDK til at køre på AArch64 i macOS-platforme.

2.5. Udfase Applet API til fjernelse (JEP 398)

Selvom dette kan være trist for mange Java-udviklere, der startede deres udviklingskarriere ved hjælp af Applet API'er, har mange webbrowsere allerede fjernet deres understøttelse af Java-plugins. Da API'en blev irrelevant, markerede denne version den til fjernelse, selvom den er blevet markeret som forældet siden version 9.

2.6. Indkapsl kraftigt JDK Internals (JEP 403)

JEP 403 repræsenterer endnu et skridt i retning af en kraftig indkapsling af JDK-internal, da den fjerner flaget –illegal-access . Platformen vil ignorere flaget, og hvis flaget er til stede, vil konsollen udsende en besked, der informerer om afbrydelsen af ​​flaget.

Denne funktion forhindrer JDK-brugere i at få adgang til interne API'er, undtagen kritiske som sun.misc.Unsafe .

2.7. Mønstertilpasning til switch (Preview) (JEP 406)

Dette er endnu et skridt hen imod mønstermatchning ved at forbedre mønstertilpasning for switch udtryk og udsagn. Det reducerer den kedelplade, der er nødvendig for at definere disse udtryk og forbedrer sprogets udtryksevne.

Lad os se to eksempler på de nye muligheder:


static record Human (String name, int age, String profession) {}

public String checkObject(Object obj) {
    return switch (obj) {
        case Human h -> "Name: %s, age: %s and profession: %s".formatted(h.name(), h.age(), h.profession());
        case Circle c -> "This is a circle";
        case Shape s -> "It is just a shape";
        case null -> "It is null";
        default -> "It is an object";
    };
}

public String checkShape(Shape shape) {
    return switch (shape) {
        case Triangle t && (t.getNumberOfSides() != 3) -> "This is a weird triangle";
        case Circle c && (c.getNumberOfSides() != 0) -> "This is a weird circle";
        default -> "Just a normal shape";
    };
}

2.8. Fjern RMI-aktivering (JEP 407)

Markeret til fjernelse i version 15, fjernede denne JEP RMI-aktiverings-API'en fra platformen i version 17.

2.9. Forseglede klasser (JEP 409)

Forseglede klasser er en del af Project Amber, og denne JEP introducerer officielt en ny funktion til sproget, selvom den var tilgængelig i preview-tilstand i JDK-versionerne 15 og 16.

Funktionen begrænser, hvilke andre klasser eller grænseflader der kan udvide eller implementere en forseglet komponent. Visning af en anden forbedring relateret til mønstertilpasning kombineret med JEP 406 vil tillade en mere sofistikeret og renere inspektion af type-, cast- og act-kodemønsteret.

Lad os se det i aktion:


int getNumberOfSides(Shape shape) {
    return switch (shape) {
        case WeirdTriangle t -> t.getNumberOfSides();
        case Circle c -> c.getNumberOfSides();
        case Triangle t -> t.getNumberOfSides();
        case Rectangle r -> r.getNumberOfSides();
        case Square s -> s.getNumberOfSides();
    };
}

2.10. Fjern den eksperimentelle AOT- og JIT-kompiler (JEP 410)

Introduceret i henholdsvis JDK 9 og JDK 10 som eksperimentelle funktioner var Ahead-Of-Time (AOT) kompilationen (JEP 295) og Just-In-Time (JIT) compileren fra GraalVM (JEP-317) funktioner med en høj udgifter til vedligeholdelse.

På den anden side havde de ingen væsentlig adoption. På grund af det fjernede denne JEP dem fra platformen, men udviklere kan stadig udnytte dem ved hjælp af GraalVM.

2.11. Fraskriv Security Manager for Removal (JEP 411)

Sikkerhedsadministratoren havde til formål at sikre klientsidens Java-kode er endnu en funktion, der er markeret til fjernelse, fordi den ikke længere er relevant.

2.12. Foreign Function and Memory API (Inkubator) (JEP 412)

Foreign Function og Memory API tillader Java-udviklere at få adgang til kode uden for JVM og administrere hukommelse ud af heapen. Målet er at erstatte JNI API og forbedre sikkerheden og ydeevnen sammenlignet med den gamle.

Denne API er en anden funktion udviklet af Project Panama, og den er blevet udviklet og forladt af JEP'erne 393, 389, 383 og 370.

Med denne funktion kan vi foretage et opkald til et C-bibliotek fra en Java-klasse:


private static final SymbolLookup libLookup;

static {
    // loads a particular C library
    var path = JEP412.class.getResource("/print_name.so").getPath();
    System.load(path);
    libLookup = SymbolLookup.loaderLookup();
}

Først er det nødvendigt at indlæse det målbibliotek, vi ønsker at kalde via API'et.

Dernæst skal vi specificere signaturen for målmetoden og til sidst kalde den:


public String getPrintNameFormat(String name) {

    var printMethod = libLookup.lookup("printName");

    if (printMethod.isPresent()) {
        var methodReference = CLinker.getInstance()
            .downcallHandle(
                printMethod.get(),
                MethodType.methodType(MemoryAddress.class, MemoryAddress.class),
                FunctionDescriptor.of(CLinker.C_POINTER, CLinker.C_POINTER)
            );

        try {
            var nativeString = CLinker.toCString(name, newImplicitScope());
            var invokeReturn = methodReference.invoke(nativeString.address());
            var memoryAddress = (MemoryAddress) invokeReturn;
            return CLinker.toJavaString(memoryAddress);
        } catch (Throwable throwable) {
            throw new RuntimeException(throwable);
        }
    }
    throw new RuntimeException("printName function not found.");
}

2.13. Vector API (Second Incubator) (JEP 414)

Vector API'en omhandler SIMD-operationen (Single Instruction, Multiple Data), hvilket betyder forskellige sæt instruktioner, der udføres parallelt. Det udnytter specialiseret CPU-hardware, der understøtter vektorinstruktioner og tillader udførelse af sådanne instruktioner som pipelines.

Som et resultat heraf vil den nye API gøre det muligt for udviklere at implementere mere effektiv kode og udnytte potentialet i den underliggende hardware.

Daglig brug af denne operation er videnskabelige lineære algebraapplikationer, billedbehandling, tegnbehandling og enhver tung aritmetisk applikation eller enhver applikation, der skal anvende en operation for flere uafhængige operander.

Lad os bruge API'et til at illustrere et simpelt vektormultiplikationseksempel:


public void newVectorComputation(float[] a, float[] b, float[] c) {
    for (var i = 0; i < a.length; i += SPECIES.length()) {
        var m = SPECIES.indexInRange(i, a.length);
        var va = FloatVector.fromArray(SPECIES, a, i, m);
        var vb = FloatVector.fromArray(SPECIES, b, i, m);
        var vc = va.mul(vb);
        vc.intoArray(c, i, m);
    }
}

public void commonVectorComputation(float[] a, float[] b, float[] c) {
    for (var i = 0; i < a.length; i ++) {
        c[i] = a[i] * b[i];
    }
}

2.14. Kontekstspecifikke deserialiseringsfiltre (JEP 415)

JEP 290, først introduceret i JDK 9, gjorde det muligt for os at validere indgående serialiserede data fra kilder, der ikke er tillid til, en almindelig kilde til mange sikkerhedsproblemer. Denne validering sker på JVM-niveau, hvilket giver mere sikkerhed og robusthed.

Med JEP 415 kan applikationer konfigurere kontekstspecifikke og dynamisk udvalgte deserialiseringsfiltre defineret på JVM-niveau. Hver deserialiseringsoperation vil påkalde sådanne filtre.

3. LTS-definition

Ændringerne forbliver ikke kun i koden – processer ændrer sig også.

Java-platformsudgivelser har en kendt historie for at være lange og upræcise. Selvom det er designet til at have en tre-årig kadence mellem udgivelser, blev det ofte en fire-årig proces.

I betragtning af den nye dynamik på markedet, hvor innovation og hurtig reaktion blev obligatorisk, besluttede teamet, der var ansvarligt for platformens udvikling, at ændre udgivelseskadencen for at tilpasse sig den nye virkelighed.

Som følge heraf er en ny seks-måneders funktionsudgivelsesmodel blevet vedtaget siden Java 10 (udgivet den 20. marts 2018).

3.1. Seks måneders funktionsudgivelsesmodel

Den nye seks-måneders funktionsudgivelsesmodel giver platformudviklerne mulighed for at frigive funktioner, når de er klar. Dette fjerner trykket ved at skubbe funktionen ind i udløseren. Ellers skulle de vente tre til fire år på at gøre funktionen tilgængelig for platformens brugere.

Den nye model forbedrer også feedback-cyklussen mellem brugere og platformens arkitekter. Det er fordi funktioner kan gøres tilgængelige i en inkuberingstilstand og kun frigives til generel brug efter adskillige interaktioner.

3.2. LTS-model

Da virksomhedsapplikationer i vid udstrækning bruger Java, er stabilitet afgørende. Desuden er det dyrt at blive ved med at understøtte og levere patch-opdateringer til alle disse versioner.

Af denne grund blev versionerne langtidsunderstøttelse (LTS) oprettet, som tilbyder brugerne udvidet support. Så sådanne versioner bliver naturligvis mere stabile og sikre på grund af fejlrettelser, ydeevneforbedringer og sikkerhedsrettelser. I tilfælde af Oracle varer denne support normalt i otte år.

Siden introduktionen af ​​ændringerne i udgivelsesmodellen var LTS-versionerne Java SE 11 (udgivet i september 2018) og Java SE 17 (udgivet i september 2021). Ikke desto mindre bragte version 17 noget nyt til modellen. Kort sagt, intervallet mellem LTS-versioner er nu to år i stedet for tre, hvilket gør Java 21 (planlagt til september 2023) sandsynligvis den næste LTS.

Et andet punkt, der er værd at nævne, er, at denne udgivelsesmodel ikke er ny. Den blev kopieret skamløst og tilpasset fra andre projekter som Mozilla Firefox, Ubuntu og andre, hvor modellen viste sig.

4. Ny udgivelsesproces

Vi baserede denne artikel på JEP 3, da den beskriver alle ændringer i processen. Tjek den for yderligere detaljer. Vi vil forsøge at give et kortfattet resumé af det her.

Givet den nye model beskrevet ovenfor, kombineret med den kontinuerlige udvikling af platformen og de nye seks måneders udgivelseskadencer (generelt juni og december), vil Java bevæge sig hurtigere. Udviklingsteamet for JDK vil starte udgivelsescyklussen for den næste funktionsudgivelse efter den proces, der beskrives herefter.

Processen begynder med gaffelen på hovedlinjen. Derefter fortsætter udviklingen i et stabiliseringsdepot, JDK/JDK$N (for eksempel JDK17). Der fortsætter udviklingen med fokus på stabilisering af udgivelsen.

Før vi dykker dybere ned i processen, lad os præcisere noget terminologi:

  • Fejl :I denne sammenhæng betyder fejl billetter eller opgaver:
    • Aktuel :Disse er enten faktiske fejl relateret til den aktuelle version (den nye ved at blive frigivet) eller justeringer af nye funktioner, der allerede er inkluderet i denne version (nye JEP'er).
    • Målrettet :Relateret til de ældre versioner og planlagt til at blive rettet eller behandlet i denne nye version
  •  Prioriteter :Lige fra P1 til P5, hvor P1 er den vigtigste, hvor vigtigheden gradvist aftager ned til P5

4.1. Nyt format

Stabiliseringsprocessen fortsætter i de næste tre måneder:

  • JDK/JDK$N-lageret fungerer som en udgivelsesgren, og på dette tidspunkt går der ingen nye JEP'er af nye JEP'er ind i arkivet.
  • Dernæst vil udviklingen i dette lager blive stabiliseret og overført til hovedlinjen, hvor andre udviklinger fortsætter.
  • Ramp down fase 1 (RDP 1):Varer mellem fire og fem uger. Udviklere dropper alle strømme P4-P5 og den målrettede P1-P3 (afhængigt af udsættelse, rettelse eller forbedring). Dette betyder, at P5+ test/docs fejl og målrettede P3+ kodefejl er valgfrie.
  • Ramp down fase 2 (RDP 2):Varer mellem tre og fire uger. Nu udskyder de alle strømme P3-P5 og den målrettede P1-P3 (afhængigt af udsættelse, rettelse eller forbedring).
  • Til sidst udgiver teamet en udgivelseskandidat-build og gør den tilgængelig for offentligheden. Denne fase varer mellem to og fem uger, og kun aktuelle P1-rettelser behandles (ved hjælp af fix).

Når alle disse cyklusser er færdige, bliver den nye udgivelse versionen General Availability (GA).

5. Hvad er det næste?

JDK arkitekter arbejder videre på mange projekter, der har til formål at modernisere platformen. Målet er at give en bedre udviklingsoplevelse og mere robuste og effektive API'er.

Som følge heraf skulle JDK 18 være ude seks måneder fra nu, selvom denne version sandsynligvis ikke vil indeholde væsentlige eller forstyrrende ændringer. Vi kan følge listen over foreslåede JEP'er målrettet til denne version i den officielle OpenJDK-projektportal.

En anden relevant nyhed, der påvirker de nuværende og fremtidige versioner, er den nye gratis vilkår og betingelser-licens, der gælder for Oracle JDK-distributionen (eller Hotspot). I de fleste tilfælde tilbyder Oracle sin distribution gratis til produktion og andre miljøer, men der er nogle få undtagelser. Igen, se venligst linket.

Som nævnt før måler den nye proces, at den næste LTS-version er version 21, og planen er at frigive den inden september 2023.

6. Konklusion

I denne artikel kiggede vi på nyhederne om den nye Java 17-version og gennemgår dens seneste udvikling, nye muligheder, supportdefinition og udgivelsescyklusproces.

Som sædvanlig er alle kodeeksempler, der bruges i denne artikel, tilgængelige på GitHub.


Java tag