Lansering av Java SE 17

Efter sex månader av utveckling har Oracle släppt plattformen Java SE 17 (Java Platform, Standard Edition 17), där den referensimplementation som används bygger på det öppna projektet OpenJDK. Bortsett från att vissa föråldrade funktioner har tagits bort, har Java SE 17 bibehållen bakåtkompatibilitet med tidigare versioner av Java-plattformen – de flesta tidigare skrivna Java-projekt kommer att fungera utan ändringar när de körs på den nya versionen. Installationsfärdiga versioner av Java SE 17 (JDK, JRE och Server JRE) har förberetts för Linux (x86_64, AArch64), Windows (x86_64) och macOS (x86_64, AArch64). Den referensimplementation av Java 17 som utvecklats inom ramen för OpenJDK-projektet är helt öppen under GPLv2-licensen med undantag för GNU ClassPath, som tillåter dynamisk länkning med kommersiella produkter.

Java SE 17 klassas som en version med långsiktig support (LTS), där uppdateringar kommer att släppas fram till 2029. Utgivningen av uppdateringar för den föregående versionen Java 16 har upphört. Den tidigare LTS-grenen Java 11 kommer att stödjas fram till 2026. Den nästa LTS-versionen planeras till september 2024. Vi påminner om att projektet från och med Java 10 har övergått till en ny utvecklingsprocess som innebär en kortare cykel för nya versioner. Den nya funktionaliteten utvecklas nu i en ständigt uppdaterad mastergren, där färdiga ändringar inkluderas, och var sjätte månad avgrenas grenar för stabilisering av de nya versionerna.

Bland nyheterna i Java 17 kan nämnas:

• En experimentell implementering av mönstermatchning i "switch"-uttryck har föreslagits, vilket möjliggör användning av flexibla mönster i "case"-etiketterna som täcker en serie värden, vilka tidigare krävde användning av omfattande kedjor av "if…else"-uttryck. Dessutom har möjligheten att hantera NULL-värden inuti "switch" säkerställts. Object o = 123L; String formatted = switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> o.toString(); };
• Stödet för inkapslade ("sealed") klasser och gränssnitt har stabiliserats, vilka inte kan användas av andra klasser och gränssnitt för arv, utvidgning eller överskrivning av implementation. Inkapslade klasser ger också ett mer deklarativt sätt att begränsa användningen av superklassen än åtkomstmodifierare, baserat på en explicit uppräkning av underklasser som är tillåtna för utvidgning. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}
• En andra preliminär implementering av API:et för Vektorer har föreslagits, vilket tillhandahåller funktioner för vektorberäkningar som utförs med hjälp av vektorinstruktioner från x86_64- och AArch64-processorer och möjliggör att operationer tillämpas samtidigt på flera värden (SIMD). Till skillnad från omfattningen av av-värde-värdesvigning av skalaroperationer som erbjuds i JIT-kompilatorn HotSpot, ger det nya API:et möjlighet att explicit styra vektoriseringen för parallell databehandling.
• En preliminär implementering av API:et för Utländsk Funktion & Minne har lagts till, som gör det möjligt för applikationer att interagera med kod och data utanför Java-runtime. Det nya API:et tillåter effektiv anrop av funktioner som inte körs i JVM och att få åtkomst till minne som inte hanteras av JVM. Till exempel kan funktioner från externa delade bibliotek anropas och data i processen nås utan att använda JNI.
• Ritmotor för macOS, som stöder Java 2D API, som i sin tur används i Swing API, har anpassats för att använda grafik-API:et Metal. Som standard används fortfarande OpenGL på macOS-plattformen, och för att aktivera stöd för Metal krävs det att parametern "-Dsun.java2d.metal=true" ställs in och att minst macOS-version 10.14.x är installerad.
• En port för macOS/AArch64-plattformen (Apple-datorer med de nya Apple M1-chippen) har lagts till. En särskild funktion hos porten är stöd för minnesskyddsmekanismen W^X (Write XOR Execute), där minnessidor inte kan vara samtidigt tillgängliga för skrivning och exekvering. (kod kan endast exekveras efter att skrivning har förhindrats, och skrivning till en minnessida är endast möjlig efter att exekvering har förhindrats).
• Endast strikt (strictfp) semantik för flyttalsuttryck har återinförts. Stödet för tillgängligheten har upphört från och med Java 1.2-versionen av semantiken "default", som inkluderade förenklingar för att fungera på mycket gamla matematiska co-processorer som x87 (efter introduktionen av SSE2-instruktioner har behovet av ytterligare semantik försvunnit).
• Nya typer av gränssnitt till pseudotillfälliga nummergeneratorer har införlivats, liksom ytterligare algoritmer för bättre kvalitet på de genererade slumptalen. Applikationerna har möjlighet att välja algoritm för pseudotillfälliga nummergeneratorer. Stödet för att generera strömmar av slumpmässiga objekt har förbättrats.
• Obligatorisk strikt inkapsling av alla interna element i JDK har införts, med undantag för kritiska API:er, som sun.misc.Unsafe. Strikt inkapsling blockerar försök att få åtkomst till interna klasser, metoder och fält från koden. Tidigare kunde strikt inkapsling inaktiveras med alternativet "—illegal-access=permit", men det har nu blivit föråldrat. För applikationer som behöver åtkomst till interna klasser, metoder och fält bör dessa explicit definieras med alternativet "—add-opens" eller med attributet Add-Opens i manifestfilen.
• Applikationerna har möjlighet att definiera filter för deserialisering av data, vilket kan bero på kontext och väljas dynamiskt i samband med specifika deserialiseringsoperationer. Definierade filter tillämpas på hela en virtuell maskin (JVM-omfattande), det vill säga omfattar inte bara själva applikationen utan även de tredjepartsbibliotek som används i applikationen.
• I Swing har metoden javax.swing.filechooser.FileSystemView.getSystemIcon lagts till för att ladda stora ikoner, vilket förbättrar gränssnittsbildningen på skärmar med hög pixeldensitet (HighDPI).
• I api:t java.net.DatagramSocket har stöd för att ansluta till Multicast-grupper införts utan att behöva använda det separata api:t java.net.MulticastSocket.
• Verktyget IGV (Ideal Graph Visualizer) har förbättrats för att säkerställa interaktiv visualisering av den mellanliggande koden i JIT-kompilatorn HotSpot VM C2.
• I JavaDoc, på samma sätt som kompilatorn javac, anges radnumret för problemlinjen i källfilen och platsen för felet när ett felrapporteras.
• Egenskapen native.encoding har lagts till, vilket återspeglar namnet på den systemkodning av tecken som används (UTF-8, koi8-r, cp1251 osv.).
• Gränssnittet java.time.InstantSource har lagts till, vilket möjliggör manipulering av tid utan koppling till tidszon.
• API:t java.util.HexFormat har lagts till för att konvertera till hexadecimalt format och vice versa.
• Kompilatorn har fått en blackhole-läge som inaktiverar undantagsoperationer för oanvänd kod (dead-code elimination), vilket kan användas vid prestandatestning.
• I Runtime har alternativet "-Xlog:async" lagts till för att skriva loggar i asynkront läge.
• Vid installation av säkrade anslutningar används TLS 1.3 som standard (tidigare användes TLS 1.2).
• Applet-API:n (java.applet.Applet*, javax.swing.JApplet) som tidigare annonserats som föråldrad har flyttats till kategorin för planerad avveckling och användes för att köra Java-applikationer i webbläsaren (har blivit irrelevant efter att Java-plugin-stödet för webbläsare upphörde).
• Security Manager har flyttats till kategorin för planerad avveckling, som länge har blivit irrelevant och inte efterfrågad efter att stödet för webbläsarpluginet har upphört.
• RMI Activation-mekanismen har tagits bort, vilket var föråldrat, flyttades till graden av val i Java 8 och används nästan inte i modern praxis.
• Den experimentella kompilatorn som stödde JIT (just-in-time) för dynamisk kompilering av Java-kod för HotSpot JVM har tagits bort från SDK, liksom AOT-läget (ahead-of-time) för kompilation av klasser till maskinkod före körning av den virtuella maskinen. Kompilatorn skrevs i Java och baserades på arbete från Graal-projektet. Det påpekas att underhållet av kompilatorn kräver stor arbetsinsats utan att vara rättfärdigat av utvecklarnas efterfrågan.

Källa: opennet.ru