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

Hvad er nyt i Java 15

new
Denne artikel er en del af en serie:• Nye funktioner i Java 8
• Nye funktioner i Java 9
• Nye funktioner i Java 10
• Nye funktioner i Java 11
• Nye funktioner i Java 12
• Nye funktioner i Java 13
• Nye funktioner i Java 14
• Hvad er nyt i Java 15 (aktuel artikel) • Nye funktioner i Java 16
• Nye funktioner i Java 17

1. Introduktion

Java 15 nåede generel tilgængelighed i september 2020 og er den næste kortsigtede udgivelse til JDK-platformen. Det bygger på adskillige funktioner fra tidligere udgivelser og giver også nogle nye forbedringer.

I dette indlæg vil vi se på nogle af de nye funktioner i Java 15 , samt andre ændringer, der er af interesse for Java-udviklere.

2. Optegnelser (JEP 384)

Recorden er en ny type klasse i Java, der gør det nemt at skabe uforanderlige dataobjekter.

Java 15, der oprindeligt blev introduceret i Java 14 som et tidligt eksempel, sigter mod at forfine nogle få aspekter, før det bliver en officiel produktfunktion.

Lad os se på et eksempel, der bruger nuværende Java, og hvordan det kunne ændre sig med poster.

2.1. Uden optegnelser

Forud for registreringer ville vi oprette et uforanderligt dataoverførselsobjekt (DTO) som:

public class Person {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

Bemærk, at der er en masse kode her for at skabe et uforanderligt objekt, der egentlig bare holder tilstanden. Alle vores felter er eksplicit defineret ved hjælp af final , vi har en enkelt alle-argument-konstruktør, og vi har en accessormetode for hvert felt. I nogle tilfælde kan vi endda erklære selve klassen som final for at forhindre enhver underklassificering.

I mange tilfælde ville vi også gå et skridt videre og tilsidesætte toString metode til at give meningsfuldt logningsoutput. Vi ville nok også ønske at tilsidesætte lig og hashCode metoder til at undgå uventede konsekvenser, når man sammenligner to forekomster af disse objekter.

2.2. Med Records

Bruger den nye post klasse, kan vi definere det samme uforanderlige dataobjekt på en meget mere kompakt måde:

public record Person(String name, int age) {
}

Der er sket et par ting her. Først og fremmest har klassedefinitionen en ny syntaks, der er specifik for record s . Denne overskrift er der, hvor vi giver detaljerne om felterne i posten.

Ved at bruge denne header kan compileren udlede de interne felter. Dette betyder, at vi ikke behøver at definere specifikke medlemsvariabler og accessorer, da de leveres som standard. Vi behøver heller ikke levere en konstruktør.

Derudover giver compileren fornuftige implementeringer til toString , lig med og hashCode metoder.

Mens du optager s eliminerer en masse boilerplate-kode, tillader de os at tilsidesætte nogle af standardadfærden . For eksempel kunne vi definere en kanonisk konstruktør, der udfører en vis validering:

public record Person(String name, int age) {
    public Person {
        if(age < 0) {
            throw new IllegalArgumentException("Age cannot be negative");
        }
    }
}

Det er værd at nævne den post s har nogle begrænsninger. Blandt andet er de altid endelige , kan de ikke erklæres abstrakte , og de kan ikke bruge native metoder.

3. Forseglede klasser (JEP 360)

I øjeblikket giverJava ingen finmasket kontrol over arven . Adgangsmodifikatorer såsom offentlige , beskyttet , privat , såvel som standardpakken-privat, giver meget grovkornet kontrol.

Til det formål er målet forseglet klasser er at tillade individuelle klasser at erklære, hvilke typer der kan bruges som undertyper. Dette gælder også for grænseflader og bestemmelse af, hvilke typer der kan implementere dem.

Forseglede klasser involverer to nye søgeord - forseglet og tilladelser :

public abstract sealed class Person
    permits Employee, Manager {
 
    //...
}

I dette eksempel har vi erklæret en abstrakt klasse ved navn Person. Vi har også specificeret, at de eneste klasser, der kan udvide det, er medarbejder og Manager . Forlænger den forseglede klasse udføres, som det er i dag i Java, ved at bruge extends søgeord:

public final class Employee extends Person {
}

public non-sealed class Manager extends Person {
}

Det er vigtigt at bemærke, at enhver klasse, der udvider en forseglet klasse skal selv erklæres forseglet , ikke-forseglet eller endelig . Dette sikrer, at klassehierarkiet forbliver begrænset og kendt af compileren.

Dette begrænsede og udtømmende hierarki er en af ​​de store fordele ved at bruge forseglet klasser . Lad os se et eksempel på dette i aktion:

if (person instanceof Employee) {
    return ((Employee) person).getEmployeeId();
} 
else if (person instanceof Manager) {
    return ((Manager) person).getSupervisorId();
}

Uden en forseglet klasse kan compileren ikke med rimelighed bestemme, at alle mulige underklasser er dækket med vores if-else udsagn. Uden et andet klausul i slutningen, vil compileren sandsynligvis udstede en advarsel, der indikerer, at vores logik ikke dækker alle tilfælde.

4. Skjulte klasser (JEP 371)

En ny funktion, der introduceres i Java 15, er kendt som skjulte klasser. Selvom de fleste udviklere ikke vil finde en direkte fordel ved dem, vil alle, der arbejder med dynamisk bytekode eller JVM-sprog, sandsynligvis finde dem nyttige.

Målet med skjulte klasser er at tillade runtime-oprettelse af klasser, der ikke er opdagelige . Det betyder, at de ikke kan forbindes af andre klasser, og de kan heller ikke opdages via refleksion. Klasser som disse har typisk en kort livscyklus, og derfor er skjulte klasser designet til at være effektive med både lastning og losning.

Bemærk, at nuværende versioner af Java giver mulighed for at oprette anonyme klasser, der ligner skjulte klasser. De stoler dog på Usikre API. Skjulte klasser har ingen sådan afhængighed.

5. Mønstertilpasningstypetjek (JEP 375)

Mønstertilpasningsfunktionen blev forhåndsvist i Java 14, og Java 15 sigter mod at fortsætte sin preview-status uden nye forbedringer.

Som en gennemgang er målet med denne funktion at fjerne en masse kedelkode, der typisk følger med forekomsten af operatør:

if (person instanceof Employee) {
    Employee employee = (Employee) person;
    Date hireDate = employee.getHireDate();
    //...
}

Dette er et meget almindeligt mønster i Java. Når vi kontrollerer, om en variabel er en bestemt type, følger vi næsten altid den med en cast til den type.

Mønstertilpasningsfunktionen forenkler dette ved at introducere en ny bindingsvariabel :

if (person instanceof Employee employee) {
    Date hireDate = employee.getHireDate();
    //...
}

Bemærk, hvordan vi giver et nyt variabelnavn, medarbejder , som en del af typetjekket. Hvis typekontrollen er sand , så caster JVM automatisk variablen for os og tildeler resultatet til den nye bindingsvariabel .

Vi kan også kombinere den nye bindingsvariabel med betingede udsagn:

if (person instanceof Employee employee && employee.getYearsOfService() > 5) {
    //...
}

I fremtidige Java-versioner er målet at udvide mønstertilpasning til andre sprogfunktioner såsom switch udsagn.

6. Foreign Memory API (JEP 383)

Adgang til fremmed hukommelse er allerede en inkuberende funktion i Java 14. I Java 15 er målet at fortsætte sin inkubationsstatus og samtidig tilføje flere nye funktioner:

  • Et nyt VarHandle API, for at tilpasse hukommelsesadgang var handles
  • Understøttelse af parallel behandling af et hukommelsessegment ved hjælp af Spliterator grænseflade
  • Forbedret understøttelse af kortlagt hukommelsessegmenter
  • Evne til at manipulere og derhenvise adresser, der kommer fra ting som native opkald

Fremmedhukommelse refererer generelt til hukommelse, der lever uden for den administrerede JVM-bunke. På grund af dette er den ikke genstand for affaldsindsamling og kan typisk håndtere utroligt store hukommelsessegmenter.

Selvom disse nye API'er sandsynligvis ikke vil påvirke de fleste udviklere direkte, vil de give en masse værdi til tredjepartsbiblioteker, der beskæftiger sig med fremmed hukommelse. Dette inkluderer distribuerede caches, denormaliserede dokumentlagre, store vilkårlige bytebuffere, hukommelseskortede filer og mere.

7. Skraldesamlere

I Java 15 vil både ZGC (JEP 377) og Shenandoah (JEP 379) ikke længere være eksperimentelle . Begge vil være understøttede konfigurationer, som teams kan vælge at bruge, mens G1-samleren forbliver standard.

Begge var tidligere tilgængelige ved hjælp af eksperimentelle funktionsflag. Denne tilgang giver udviklere mulighed for at teste de nye skraldeopsamlere og indsende feedback uden at downloade en separat JDK eller tilføjelse.

En bemærkning om Shenandoah:det er ikke tilgængeligt fra alle leverandørers JDK'er - mest bemærkelsesværdigt inkluderer Oracle JDK det ikke.

8. Andre ændringer

Der er flere andre bemærkelsesværdige ændringer i Java 15.

Efter flere runder med forhåndsvisninger i Java 13 og 14 vil tekstblokke være en fuldt understøttet produktfunktion i Java 15.

Nyttige nul pointer-undtagelser, der oprindeligt blev leveret i Java 14 under JEP 358, er nu aktiveret som standard.

Den gamle DatagramSocket API er blevet omskrevet. Dette er en opfølgning på en omskrivning i Java 14 af Socket API. Selvom det ikke vil påvirke de fleste udviklere, er det interessant, da det er en forudsætning for Project Loom.

Det skal også bemærkes, at Java 15 inkluderer kryptografisk understøttelse af Edwards-Curve Digital Signature Algorithm. EdDSA er et moderne signaturskema med elliptisk kurve, der har flere fordele i forhold til de eksisterende signatursystemer i JDK.

Endelig er flere ting blevet forældet i Java 15. Forspændt låsning, Solaris/SPARC-porte og RMI-aktivering er alle fjernet eller planlagt til fjernelse i en fremtidig udgivelse.

Bemærk, at Nashorn JavaScript-motoren, der oprindeligt blev introduceret i Java 8, nu er fjernet. Med introduktionen af ​​GraalVM og andre VM-teknologier for nylig, er det klart, at Nashorn ikke længere har en plads i JDK-økosystemet.

9. Konklusion

Java 15 bygger på adskillige funktioner fra tidligere udgivelser, herunder optegnelser, tekstblokke, nye skraldeindsamlingsalgoritmer og mere. Den tilføjer også nye forhåndsvisningsfunktioner, herunder lukkede klasser og skjulte klasser .

Da Java 15 ikke er en langsigtet supportudgivelse, kan vi forvente, at support til den slutter i marts 2021. På det tidspunkt kan vi se frem til Java 16, efterfulgt kort efter med en ny langsigtet supportversion i Java 17.

Næste » Nye funktioner i Java 16« ForrigeNye funktioner i Java 14
Java tag