Java SE 17 udgivelse

Efter seks måneders udvikling har Oracle frigivet Java SE 17 (Java Platform, Standard Edition 17) platformen, som bruger OpenJDK open source-projektet som referenceimplementering. Med undtagelse af fjernelse af nogle forældede funktioner, bevarer Java SE 17 bagudkompatibilitet med tidligere udgivelser af Java-platformen - de fleste tidligere skrevne Java-projekter vil stadig fungere uden ændringer, når de køres under den nye version. Klar til at installere builds af Java SE 17 (JDK, JRE og Server JRE) er forberedt til Linux (x86_64, AArch64), Windows (x86_64) og macOS (x86_64, AArch64). Java 17-referenceimplementeringen er udviklet af OpenJDK-projektet og er fuldt åben under GPLv2-licensen med GNU ClassPath-undtagelser for at tillade dynamiske links til kommercielle produkter.

Java SE 17 er klassificeret som en Long Term Support (LTS) udgivelse, som vil fortsætte med at modtage opdateringer indtil 2029. Opdateringer til den tidligere Java 16 milepælsudgivelse er afbrudt. Den tidligere LTS-gren af ​​Java 11 vil blive understøttet indtil 2026. Den næste LTS-udgivelse er planlagt til september 2024. Lad os minde dig om, at fra og med udgivelsen af ​​Java 10 skiftede projektet til en ny udviklingsproces, hvilket indebar en kortere cyklus for dannelsen af ​​nye udgivelser. Ny funktionalitet udvikles nu i én konstant opdateret mastergren, som omfatter færdige ændringer, og hvorfra filialer forgrenes hvert halve år for at stabilisere nye udgivelser.

Nye funktioner i Java 17 inkluderer:

  • Der foreslås en eksperimentel implementering af mønstertilpasning i "switch"-udtryk, som gør det muligt at bruge ikke nøjagtige værdier i "case"-etiketter, men fleksible skabeloner, der dækker en række værdier på én gang, som det tidligere var nødvendigt at bruge besværligt for. kæder af "hvis ... andet" udtryk. Derudover har "switch" evnen til at håndtere NULL-værdier. Objekt o = 123L; String formatted = switch (o) { case Heltal i -> String.format("int %d", i); case Lang l -> String.format("lang %d", l); kasus Dobbelt d -> String.format("dobbelt %f", d); case String s -> String.format("String %s", s); default -> o.toString(); };
  • Stabiliseret understøttelse af forseglede klasser og grænseflader, som ikke kan bruges af andre klasser og grænseflader til at arve, udvide eller tilsidesætte implementeringen. Forseglede klasser giver også en mere deklarativ måde at begrænse brugen af ​​en superklasse på end adgangsmodifikatorer, baseret på en eksplicit liste over de underklasser, der er tilladt for udvidelse. pakke com.example.geometry; offentlig forseglet klasse Form tillader com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}
  • En anden forhåndsvisning af Vector API foreslås, som giver funktioner til vektorberegninger, der udføres ved hjælp af vektorinstruktioner på x86_64- og AArch64-processorer og tillader operationer at blive anvendt samtidigt på flere værdier (SIMD). I modsætning til funktionerne i HotSpot JIT-kompileren til autovektorisering af skalaroperationer, gør den nye API det muligt eksplicit at kontrollere vektorisering til parallel databehandling.
  • Tilføjet en forhåndsvisning af Foreign Function & Memory API, som tillader applikationer at interagere med kode og data uden for Java-runtime. Den nye API giver dig mulighed for effektivt at kalde ikke-JVM-funktioner og få adgang til ikke-JVM-administreret hukommelse. For eksempel kan du kalde funktioner fra eksterne delte biblioteker og få adgang til procesdata uden at bruge JNI.
  • MacOS-gengivelsesmotoren, der driver Java 2D API, som igen driver Swing API, er blevet tilpasset til at bruge Metal graphics API. MacOS-platformen fortsætter med at bruge OpenGL som standard, og aktivering af Metal-understøttelse kræver indstilling "-Dsun.java2d.metal=true" og som minimum kører macOS 10.14.x.
  • Tilføjet en port til macOS/AArch64-platformen (Apple-computere baseret på de nye Apple M1-chips). En særlig funktion ved porten er understøttelse af W^X (Write XOR Execute) hukommelsesbeskyttelsesmekanismen, hvor hukommelsessider ikke kan tilgås samtidigt til skrivning og udførelse. (koden kan kun udføres, efter at skrivning er deaktiveret, og skrivning til en hukommelsesside er kun mulig, efter at udførelsen er deaktiveret).
  • Vendte tilbage til kun at bruge strictfp semantik til udtryk med flydende komma. Understøttelse af "standard" semantikken, tilgængelig siden udgivelsen af ​​Java 1.2, er blevet afbrudt, herunder forenklinger for at arbejde på systemer med meget gamle x87 matematiske coprocessorer (efter fremkomsten af ​​SSE2-instruktioner forsvandt behovet for yderligere semantik).
  • Nye typer grænseflader til pseudorandom-talgeneratorer er blevet implementeret, og yderligere algoritmer er blevet implementeret for bedre generering af tilfældige tal. Applikationer får mulighed for at vælge en algoritme til generering af pseudotilfældige tal. Forbedret understøttelse af generering af tilfældige objektstrømme.
  • Tvinget streng indkapsling af alle JDK-internal, med undtagelse af kritiske API'er såsom sun.misc.Unsafe. Streng indkapsling blokerer forsøg fra kode til adgang til interne klasser, metoder og felter. Tidligere kunne streng indkapslingstilstand deaktiveres ved at bruge "--illegal-access=permit", men dette er nu blevet forældet. Programmer, der kræver adgang til interne klasser, metoder og felter, bør udtrykkeligt definere dem ved hjælp af --add-opens-indstillingen eller Add-Opens-attributten i manifestfilen.
  • Applikationer får mulighed for at definere dataserialiseringsfiltre, som kan være kontekstafhængige og dynamisk udvalgt baseret på specifikke deserialiseringsoperationer. De angivne filtre gælder for hele den virtuelle maskine (JVM-dækkende), dvs. dækker ikke kun selve applikationen, men også de tredjepartsbiblioteker, der bruges i applikationen.
  • Swing har tilføjet javax.swing.filehooser.FileSystemView.getSystemIcon-metoden til at indlæse store ikoner for at forbedre brugergrænsefladen på skærme med høj DPI.
  • Java.net.DatagramSocket API'en giver understøttelse af tilslutning til Multicast-grupper uden behov for en separat java.net.MulticastSocket API.
  • IGV-værktøjet (Ideal Graph Visualizer) er blevet forbedret og giver interaktiv visualisering af mellemkoderepræsentation i HotSpot VM C2 JIT-kompileren.
  • I JavaDoc, analogt med javac-kompileren, er nummeret på den problematiske linje i kildefilen og placeringen af ​​fejlen nu angivet, når der udlæses en fejl.
  • Tilføjet egenskaben native.encoding, der afspejler navnet på systemkarakterkodningen (UTF-8, koi8-r, cp1251 osv.).
  • Java.time.InstantSource-grænsefladen er blevet tilføjet, hvilket tillader tidsmanipulation uden reference til en tidszone.
  • Tilføjet java.util.HexFormat API til konvertering til hexadecimal repræsentation og omvendt.
  • En sorthulstilstand er blevet tilføjet til compileren, som deaktiverer død-kode-elimineringsoperationer, som kan bruges, når der udføres ydeevnetest.
  • Tilføjet "-Xlog:async" mulighed til Runtime for at optage logfiler i asynkron tilstand.
  • Ved etablering af sikre forbindelser er TLS 1.3 aktiveret som standard (tidligere blev TLS 1.2 brugt).
  • Den tidligere erklærede forældede Applet API (java.applet.Applet*, javax.swing.JApplet), som blev brugt til at køre Java-applikationer i browseren, er blevet flyttet til kategorien planlagt til fjernelse (mistet relevans efter endt support til Java-plugin til browsere).
  • Security Manager, som for længst har mistet sin relevans og viste sig at være uopkrævet efter endt support til browser-plugin, er blevet flyttet til kategorien af ​​dem, der er planlagt til fjernelse.
  • RMI-aktiveringsmekanismen er blevet fjernet, som er forældet, henvist til kategorien af ​​en option i Java 8 og næsten aldrig bruges i moderne praksis.
  • En eksperimentel compiler, der understøtter JIT (just-in-time) til dynamisk kompilering af Java-kode til HotSpot JVM, såvel som tilstanden for forudgående kompilering (AOT, forud for tid) af klasser til maskinkode, før den virtuelle maskine startes , er blevet fjernet fra SDK. Compileren blev skrevet i Java og baseret på arbejdet i Graal-projektet. Det bemærkes, at compiler vedligeholdelse kræver meget arbejdskraft, hvilket ikke er berettiget, når der ikke er efterspørgsel fra udviklere.

Kilde: opennet.ru

Tilføj en kommentar