Java Development Kit 15, Oracle's implementering af den næste version af Java SE (Standard Edition), bliver tilgængelig som en produktionsudgivelse i dag 15. september 2020. Højdepunkter i JDK 15 inkluderer tekstblokke, skjulte klasser, et API til fremmedhukommelsesadgang, Z Garbage Collector og eksempler på forseglede klasser, mønstermatchning og poster.
JDK 15 er kun en kortvarig frigivelse, der kun understøttes med Oracle Premier Support i seks måneder, indtil JDK 16 ankommer næste marts. JDK 17, den næste langvarige supportudgivelse, der skal understøttes af Oracle i otte år, forventes at ankomme om et år fra nu, ifølge Oracles seks måneders frigivelseskadence for Java SE-versioner.
Udviklere kan se på JDK 15 nu for at få en idé om, hvad der vil være i JDK 17, sagde Georges Saab, præsident for Oracle's Java Platform Group. Den nuværende LTS-udgivelse er JDK 11, som ankom i september 2018. LTS-udgivelser ankommer hvert tredje år. JDK 15 følger JDK 14, som blev frigivet den 17. marts 2020.
De nye funktioner og ændringer i OpenJDK 15:
- En anden inkubator af en fremmed-hukommelsesadgang API, som ville lade Java-programmer sikkert og effektivt få adgang til fremmed hukommelse uden for Java-bunken. API'et skal være i stand til at operere på forskellige former for fremmed hukommelse, såsom native, vedvarende og administreret bunke. Mange Java-programmer har adgang til fremmed hukommelse, såsom Ignite og MapDB. API'en vil hjælpe med at undgå omkostningerne og uforudsigeligheden forbundet med affaldsindsamling, dele hukommelse på tværs af processer og serialisere og deserialisere hukommelsesindhold ved at kortlægge filer på hukommelsen. Java API giver i øjeblikket ikke en tilfredsstillende løsning for at få adgang til fremmed hukommelse. Men med det nye forslag bør det ikke være muligt for API'en at underminere JVM's sikkerhed. Denne kapacitet gennemgår en tidligere inkubatorfase i JDK 14 med forbedringer, der tilbydes i JDK 15.
- En forhåndsvisning af forseglede klasser. Sammen med grænseflader begrænser forseglede klasser, hvilke andre klasser eller grænseflader der kan udvide eller implementere dem. Målene med denne funktion inkluderer at tillade forfatteren af en klasse eller grænseflade at kontrollere, hvilken kode der er ansvarlig for at implementere den, give en mere deklarativ måde end adgangsmodifikatorer for at begrænse brugen af en superklasse og understøtte fremtidige retninger i mønstermatchning ved at understøtte den udtømmende analyse af mønstre.
- Fjernelse af kildekode og understøttelse af build til Solaris / SPARC, Solaris / x64 og Linux / SPARC-porte, som blev afskaffet til fjernelse i JDK 14 med det formål at fjerne dem i en fremtidig udgivelse. Mange projekter og funktioner i udvikling som Valhalla, Loom og Panama kræver betydelige ændringer i CPU-arkitektur og operativsystemspecifik kode. Drop support til Solaris- og SPARC-porte gør det muligt for bidragydere til OpenJDK-samfundet at fremskynde udviklingen af nye funktioner, der vil flytte platformen fremad. Både Solaris og SPARC er blevet afløst af de seneste år af Linux OS og Intel-processorer.
- Optegnelser, som er klasser, der fungerer som gennemsigtige bærere af uforanderlige data, ville blive inkluderet i en anden preview-version i JDK 15 efter debut som en tidlig forhåndsvisning i JDK 14. Målene i planen inkluderer udformning af en objektorienteret konstruktion, der udtrykker en enkel aggregering af værdier, der hjælper programmører med at fokusere på modellering af uforanderlige data snarere end udvidelig adfærd, automatisk implementering af datadrevne metoder såsom ligemænd og vurderere og bevarelse af langvarige Java-principper som nominel typing og migreringskompatibilitet. Optegnelser kan betragtes som nominelle tupler.
- Kryptografiske signaturer baseret på Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA er en moderne elliptisk kurveskema med fordele i forhold til eksisterende signaturordninger i JDK. EdDSA vil kun blive implementeret i SunEC-udbyderen. EdDSA er efterspurgt på grund af sin forbedrede sikkerhed og ydeevne sammenlignet med andre signaturordninger; det understøttes allerede i kryptobiblioteker som OpenSSL og BoringSSL.
- Genimplementering af den ældre DatagramSocket API ved at erstatte de underliggende implementeringer af
java.net.datagram.Socketogjava.net.MulticastSocketAPI'er med enklere og mere moderne implementeringer, der 1. er nemme at debugge og vedligeholde og 2. arbejde med virtuelle tråde, der i øjeblikket udforskes i Project Loom. Den nye plan er en opfølgning på JDK Enhancement Proposal 353, der genimplementerede den ældre Socket API. De nuværende implementeringer afjava.net.datagram.Socketogjava.net.MulticastSocketgår tilbage til JDK 1.0 og en tid, hvor IPv6 stadig var under udvikling. Således er den nuværende implementering afMulticastSocketforsøger at forene IPv4 og IPv6 på måder, der er svære at vedligeholde. - Deaktivering af forspændt låsning som standard og afskaffelse af alle relaterede kommandolinjemuligheder. Målet er at bestemme behovet for fortsat understøttelse af den dyre-til-vedligeholdelse af ældre synkroniseringsoptimering af forspændt låsning, som bruges i den virtuelle HotSpot-maskine til at reducere omkostningerne ved uforsynet låsning. Selvom nogle Java-applikationer kan se en regression i ydeevne med forudindtaget låsning deaktiveret, er præstationsgevinsterne ved forudindtaget låsning generelt mindre tydelige, end de plejede at være.
- En anden forhåndsvisning af mønstermatchning til
forekomst af, efter en tidligere forhåndsvisning i JDK 14. Mønstertilpasning tillader fælles logik i et program, hovedsageligt den betingede udvinding af komponenter fra objekter, til at blive udtrykt lettere og koncist. Sprog som Haskell og C # har taget mønstermatchning på grund af dens kortfattethed og sikkerhed. - Skjulte klasser, dvs. klasser, der ikke kan bruges direkte af bytecode for andre klasser, er beregnet til brug af rammer, der genererer klasser i løbetid, og som bruger dem indirekte gennem refleksion. En skjult klasse kan defineres som medlem af en adgangskontrol reden og kan aflæsses uafhængigt af andre klasser. Forslaget vil forbedre effektiviteten af alle sprog på JVM ved at gøre det muligt for en standard API at definere skjulte klasser, der ikke kan findes og har en begrænset livscyklus. Rammer inden for og uden for JDK ville være i stand til dynamisk at generere klasser, der i stedet kunne definere skjulte klasser. Mange sprog bygget på JVM er afhængige af dynamisk klassegenerering for fleksibilitet og effektivitet. Målene i dette forslag inkluderer: at tillade rammer at definere klasser som ikke-synlige implementeringsoplysninger om rammen, så de ikke kan knyttes sammen af andre klasser eller opdages gennem refleksion; support til udvidelse af en adgangskontrol reden med ikke-opdagelige klasser; og støtte til aggressiv aflæsning af ikke-opdagelige klasser, så rammer har fleksibiliteten til at definere så mange som nødvendigt. Et andet mål er at afskaffe den ikke-standard API,
misc.Unsafe :: defineAnonymousClass, med det formål at afskaffe fjernelse i en fremtidig frigivelse. Java-sproget skal heller ikke ændres som et resultat af dette forslag. - Z Garbage Collector (ZGC) dimitterer fra en eksperimentel funktion til et produkt under dette forslag. Integreret i JDK 11, som ankom i september 2018, er ZGC en skalerbar affaldssamler med lav latens. ZGC blev introduceret som en eksperimentel kapacitet, fordi Java's udviklere besluttede, at en funktion af denne størrelse og kompleksitet skulle bringes omhyggeligt og gradvist ind. Siden da er der blevet tilføjet en række forbedringer, der spænder fra samtidig aflæsning af klassen, uforpligtende ubrugt hukommelse og understøttelse af klassedatadeling til forbedret NUMA-bevidsthed og pre-berøring med bunke med flere tråde. Den maksimale dyngestørrelse er også øget fra fire terabyte til 16 terabyte. ZGC adresserer ydeevneproblemer i applikationer, der involverer enorme mængder data, såsom maskinindlæring, hvor brugerne vil være sikre på, at behandling af data ikke vil være genstand for uforudsigelighed eller lange pauser på grund af affaldsindsamling. Understøttede platforme inkluderer Linux, Windows og MacOS.
- Tekstblokke, der er vist i både JDK 14 og JDK 13, har til formål at forenkle opgaven med at skrive Java-programmer ved at gøre det let at udtrykke strenge, der spænder over flere kildekodelinjer, mens man undgår escape-sekvenser i almindelige tilfælde. En tekstblok er en strenglinje med flere linjer, der undgår behovet for de fleste escape-sekvenser, automatisk formaterer strengen på en forudsigelig måde og tilbyder udvikleren kontrol over formatet, når det ønskes. Et mål med forslaget om tekstblokke er at forbedre læsbarheden af strenge i Java-programmer, der betegner kode skrevet på ikke-Java-sprog. Et andet mål er at støtte migration fra strenglitteraler ved at bestemme, at enhver ny konstruktion kan udtrykke det samme sæt strenge som en strenglitteral, fortolke de samme flugtsekvenser og manipuleres på samme måde som en strenglitteral. OpenJDK-udviklerne håber at tilføje escape-sekvenser for at styre eksplicit hvidt rum og newline-kontrol.
- Shenandoah-affaldssamleren med lav pausetid ville blive en produktionsfunktion og bevæge sig ud af det eksperimentelle stadium. Det var blevet integreret i JDK 12 for et år siden.
- Fjernelse af Nashorn, som debuterede i JDK 8 i marts 2014, men siden er blevet forældet af teknologier som GraalVM. OpenJDK 15-forslaget kræver fjernelse af Nashorn API'er og jjs-kommandolinjeværktøjet, der bruges til at påkalde Nashorn.
- Forældelse af RMI-aktiveringsmekanismen til fremtidig fjernelse. RMI-aktiveringsmekanismen er en forældet del af RMI, der har været valgfri siden Java 8. RMI-aktivering pålægger en løbende vedligeholdelsesbyrde. Ingen anden del af RMI vil blive udfaset.
