JDK 15: De nya funktionerna i Java 15

Java Development Kit 15, Oracles implementering av nästa version av Java SE (Standard Edition), blir tillgängligt som en produktionsrelease idag, den 15 september 2020. Höjdpunkterna i JDK 15 inkluderar textblock, dolda klasser, ett API för åtkomst till främmande minne, Z Garbage Collector och förhandsgranskningar av förseglade klasser, mönstermatchning och poster.

JDK 15 är bara en kortvarig version, bara för att stödjas med Oracle Premier Support i sex månader tills JDK 16 kommer i mars nästa år. JDK 17, nästa långtidsstödutgåva, som kommer att stödjas av Oracle i åtta år, är planerad att anlända ett år från och med nu, enligt Oracles sex månaders släppkadens för Java SE-versioner.

Utvecklare kan titta på JDK 15 nu för att få en uppfattning om vad som kommer att bli i JDK 17, sa Georges Saab, ordförande för Oracle's Java Platform Group. Den nuvarande LTS-utgåvan är JDK 11, som anlände i september 2018. LTS-utgåvor anländer vart tredje år. JDK 15 följer JDK 14, som släpptes den 17 mars 2020. 

De nya funktionerna och förändringarna i OpenJDK 15:

  • En andra inkubator av ett främmande minnesåtkomst-API, som låter Java-program säkert och effektivt komma åt främmande minne utanför Java-högen. API: t ska kunna fungera på olika typer av främmande minne, såsom inbyggt, ihållande och hanterat hög. Många Java-program får åtkomst till främmande minne, till exempel Ignite och MapDB. API: et skulle hjälpa till att undvika kostnaden och oförutsägbarheten i samband med insamling av skräp, dela minne över processer, och serialisera och deserialisera minnesinnehåll genom att mappa filer till minnet. Java API ger för närvarande inte en tillfredsställande lösning för åtkomst till främmande minne. Men med det nya förslaget borde det inte vara möjligt för API: et att undergräva säkerheten för JVM. Denna funktion går igenom en tidigare inkubatorfas i JDK 14, med förbättringar som erbjuds i JDK 15. 
  • En förhandsvisning av förseglade klasser. Tillsammans med gränssnitt begränsar förseglade klasser vilka andra klasser eller gränssnitt som kan förlänga eller implementera dem. Målen för den här funktionen inkluderar att låta författaren till en klass eller ett gränssnitt styra vilken kod som är ansvarig för att implementera den, tillhandahålla ett mer deklarativt sätt än åtkomstmodifierare för att begränsa användningen av en superklass och stödja framtida riktningar i mönstermatchning genom att understödja det uttömmande analys av mönster.
  • Borttagning av källkod och byggsupport för Solaris / SPARC, Solaris / x64 och Linux / SPARC-portar, som avskaffades för borttagning i JDK 14 med avsikt att ta bort dem i en framtida version. Många projekt och funktioner i utveckling som Valhalla, Loom och Panama kräver betydande ändringar av CPU-arkitektur och operativsystemspecifik kod. Att tappa stöd för Solaris- och SPARC-portar gör det möjligt för bidragsgivare till OpenJDK-communityn att påskynda utvecklingen av nya funktioner som kommer att flytta plattformen framåt. Både Solaris och SPARC har ersatts av Linux OS och Intel-processorer de senaste åren.
  • Skivor, som är klasser som fungerar som transparenta bärare för oföränderliga data, skulle inkluderas i en andra förhandsgranskningsversion i JDK 15, efter att ha debuterat som en tidig förhandsgranskning i JDK 14. Målen i planen inkluderar utformning av en objektorienterad konstruktion som uttrycker en enkel aggregering av värden, vilket hjälper programmerare att fokusera på att modellera oföränderliga data snarare än utdragbart beteende, automatiskt implementera datadrivna metoder som likvärdiga och bedömare, och bevara långvariga Java-principer som nominell typning och migreringskompatibilitet. Rekord kan ses som nominella tupler. 
  • Kryptografiska signaturer baserade på Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA är ett modernt elliptiskt kurvschema med fördelar jämfört med befintliga signaturscheman i JDK. EdDSA kommer endast att implementeras i SunEC-leverantören. EdDSA är efterfrågad på grund av sin förbättrade säkerhet och prestanda jämfört med andra signaturscheman; det stöds redan i kryptobibliotek som OpenSSL och BoringSSL.
  • Återimplementera det äldre DatagramSocket API genom att ersätta de underliggande implementeringarna av  java.net.datagram.Socketoch java.net.MulticastSocketAPI: erna med enklare och modernare implementeringar som 1. är lätta att felsöka och underhålla och 2. arbeta med virtuella trådar som för närvarande utforskas i Project Loom. Den nya planen är en uppföljning av JDK Enhancement Proposal 353 som återimplementerade det äldre Socket API. De nuvarande implementeringarna av java.net.datagram.Socketoch java.net.MulticastSocketgår tillbaka till JDK 1.0 och en tid då IPv6 fortfarande var under utveckling. Således MulticastSocket försöker den nuvarande implementeringen av  att förena IPv4 och IPv6 på sätt som är svåra att underhålla.
  • Inaktiverar förspänd låsning som standard och avskaffar alla relaterade kommandoradsalternativ. Målet är att avgöra behovet av fortsatt stöd för den dyrbara att upprätthålla äldre synkroniseringsoptimering av partisk låsning, som används i den virtuella HotSpot-maskinen för att minska omkostnaderna för oavsiktlig låsning. Även om vissa Java-applikationer kan se en regression i prestanda med partisk låsning avaktiverad, är prestationsvinsterna för partisk låsning i allmänhet mindre uppenbara än de brukade vara.
  • En andra förhandsgranskning av mönstermatchning för instanceof, efter en tidigare förhandsgranskning i JDK 14. Mönstermatchning tillåter gemensam logik i ett program, huvudsakligen villkorlig utvinning av komponenter från objekt, att uttrycka sig enklare och mer kortfattat. Språk som Haskell och C # har tagit mönstermatchning för sin korthet och säkerhet.
  • Dolda klasser, dvs. klasser som inte kan användas direkt av bytkoden för andra klasser, är avsedda att användas av ramverk som genererar klasser vid körning och som använder dem indirekt genom reflektion. En dold klass kan definieras som medlem i ett åtkomstkontrollboet och kan lossas oberoende av andra klasser. Förslaget skulle förbättra effektiviteten på alla språk på JVM genom att möjliggöra för ett standard-API att definiera dolda klasser som inte kan upptäckas och har en begränsad livscykel. Ramar inom och utanför JDK skulle kunna generera dynamiskt klasser som istället skulle kunna definiera dolda klasser. Många språk som bygger på JVM är beroende av dynamisk klassgenerering för flexibilitet och effektivitet. Målen med detta förslag inkluderar: att låta ramar definiera klasser som icke-upptäckbara detaljer om implementeringen av ramverket,så de kan inte kopplas mot andra klasser eller upptäckas genom reflektion; stöd för att utvidga ett åtkomstkontrollbo med icke-upptäckbara klasser; och stöd för aggressiv lossning av icke-upptäckbara klasser, så ramar har flexibiliteten att definiera så många som behövs. Ett annat mål är att avskaffa det icke-standardiserade API: et, misc.Unsafe::defineAnonymousClass, med avsikt att avskaffas för borttagning i en framtida släpp. Java-språket ska inte ändras till följd av detta förslag.
  • Z Garbage Collector (ZGC) utexamineras från en experimentell funktion till en produkt enligt detta förslag. Integrerad i JDK 11, som anlände i september 2018, är ZGC en skalbar skräpsamlare med låg latens. ZGC introducerades som en experimentell förmåga eftersom Java-utvecklare bestämde att en funktion av denna storlek och komplexitet skulle tas försiktigt och gradvis in. Sedan dess har ett antal förbättringar lagts till, allt från samtidig klassavlastning, frigöring av oanvänt minne och stöd för klassdata-delning till förbättrad NUMA-medvetenhet och multitrådad högröring. Dessutom har den maximala högstorleken ökat från fyra terabyte till 16 terabyte. ZGC adresserar prestationsproblem i applikationer som involverar stora mängder data, såsom maskininlärningdär användare vill vara säkra på att bearbetning av data inte kommer att bli föremål för oförutsägbarhet eller långa pauser på grund av skräpinsamling. Plattformar som stöds inkluderar Linux, Windows och MacOS.
  • Textblock, förhandsgranskade i både JDK 14 och JDK 13, är avsedda att förenkla uppgiften att skriva Java-program genom att göra det enkelt att uttrycka strängar som sträcker sig över flera rader med källkod, samtidigt som man undviker escape-sekvenser i vanliga fall. Ett textblock är en bokstav med flera rader som undviker behovet av de flesta escape-sekvenser, automatiskt formaterar strängen på ett förutsägbart sätt och erbjuder utvecklaren kontroll över formatet om så önskas. Ett mål med textblockförslaget är att förbättra läsbarheten för strängar i Java-program som betecknar kod skriven på icke-Java-språk. Ett annat mål är att stödja migrering från stränglitteraler genom att föreskriva att varje ny konstruktion kan uttrycka samma uppsättning strängar som en stränglitterär, tolka samma escape-sekvenser och manipuleras på samma sätt som en stränglitterär.OpenJDK-utvecklarna hoppas kunna lägga till escape-sekvenser för att hantera tydligt vitt utrymme och newline-kontroll.
  • Shenandoah sopor med låg paus-tid skulle bli en produktionsfunktion och flytta ut ur experimentstadiet. Den hade integrerats i JDK 12 för ett år sedan.
  • Borttagning av Nashorn, som debuterade i JDK 8 i mars 2014, men som sedan dess har blivit föråldrad av tekniker som GraalVM. OpenJDK 15-förslaget kräver att Nashorn API: er och det jjs kommandoradsverktyg som används för att åberopa Nashorn ska tas bort.
  • Avskrivning av RMI-aktiveringsmekanismen för framtida borttagning. RMI-aktiveringsmekanismen är en föråldrad del av RMI som har varit valfri sedan Java 8. RMI-aktivering medför en pågående underhållsbörda. Ingen annan del av RMI kommer att avskrivas.