Java Development Kit 15, Oracles implementering av neste versjon av Java SE (Standard Edition), blir tilgjengelig som en produksjonsutgivelse i dag 15. september 2020. Høydepunkter i JDK 15 inkluderer tekstblokker, skjulte klasser, et fremmed-minnetilgang API, Z Garbage Collector, og forhåndsvisninger av forseglede klasser, mønstermatching og poster.
JDK 15 er bare en kortsiktig utgivelse, bare for å få støtte med Oracle Premier Support i seks måneder til JDK 16 kommer i mars neste år. JDK 17, den neste Long-Term Support-utgivelsen, som skal støttes av Oracle i åtte år, skal ankomme ett år fra nå, i henhold til Oracles seks måneders utgivelseskadens for Java SE-versjoner.
Utviklere kan se på JDK 15 nå for å få en ide om hva som vil være i JDK 17, sa Georges Saab, president for Oracle's Java Platform Group. Den nåværende LTS-utgivelsen er JDK 11, som ankom i september 2018. LTS-utgivelser ankommer hvert tredje år. JDK 15 følger JDK 14, som ble utgitt 17. mars 2020.
De nye funksjonene og endringene i OpenJDK 15:
- En annen inkubator av et API for fremmedminnetilgang, som vil la Java-programmer trygt og effektivt få tilgang til utenlandsk minne utenfor Java-haugen. API-en skal kunne operere på forskjellige typer fremmed minne, for eksempel innfødt, vedvarende og administrert haug. Mange Java-programmer får tilgang til fremmed minne, for eksempel Ignite og MapDB. API-et vil bidra til å unngå kostnadene og uforutsigbarheten knyttet til søppelinnsamling, dele minne på tvers av prosesser, og serieisere og deserialisere minneinnhold ved å kartlegge filer på minnet. Java API gir for øyeblikket ikke en tilfredsstillende løsning for tilgang til fremmed minne. Men med det nye forslaget, burde det ikke være mulig for API å undergrave sikkerheten til JVM. Denne muligheten går gjennom en tidligere inkubatorfase i JDK 14, med forbedringer som tilbys i JDK 15.
- En forhåndsvisning av forseglede klasser. Sammen med grensesnitt begrenser forseglede klasser hvilke andre klasser eller grensesnitt som kan utvide eller implementere dem. Målene med denne funksjonen inkluderer å tillate forfatteren av en klasse eller et grensesnitt å kontrollere hvilken kode som er ansvarlig for å implementere den, gi en mer deklarativ måte enn tilgangsmodifikatorer for å begrense bruken av en superklasse, og støtte fremtidige retninger i mønstermatching ved å underbygge det uttømmende analyse av mønstre.
- Fjerning av kildekode og byggestøtte for Solaris / SPARC, Solaris / x64 og Linux / SPARC-porter, som ble avviklet for fjerning i JDK 14 med den hensikt å fjerne dem i en fremtidig utgivelse. Mange prosjekter og funksjoner i utvikling som Valhalla, Loom og Panama krever betydelige endringer i CPU-arkitektur og operativsystem-spesifikk kode. Hvis du slipper støtte for Solaris- og SPARC-porter, kan bidragsytere til OpenJDK-fellesskapet akselerere utviklingen av nye funksjoner som vil føre plattformen videre. Både Solaris og SPARC har blitt erstattet de siste årene av Linux OS og Intel-prosessorer.
- Plater, som er klasser som fungerer som gjennomsiktige bærere for uforanderlige data, vil bli inkludert i en annen forhåndsversjonsversjon i JDK 15, etter debut som en tidlig forhåndsvisning i JDK 14. Målene i planen inkluderer utforming av en objektorientert konstruksjon som uttrykker en enkel aggregering av verdier, som hjelper programmerere med å fokusere på modellering av uforanderlige data i stedet for utvidbar oppførsel, automatisk implementering av datadrevne metoder som likemenn og vurderere, og bevaring av langvarige Java-prinsipper som nominell skriving og migreringskompatibilitet. Records kan betraktes som nominelle tupler.
- Kryptografiske signaturer basert på Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA er et moderne elliptisk kurvesystem med fordeler i forhold til eksisterende signaturordninger i JDK. EdDSA vil bare bli implementert i SunEC-leverandøren. EdDSA er etterspurt på grunn av forbedret sikkerhet og ytelse sammenlignet med andre signaturordninger; den støttes allerede i kryptobiblioteker som OpenSSL og BoringSSL.
- Implementering av den eldre DatagramSocket API ved å erstatte de underliggende implementeringene av
java.net.datagram.Socketogjava.net.MulticastSocketAPI-er med enklere og mer moderne implementeringer som 1. er enkle å feilsøke og vedlikeholde og 2. arbeide med virtuelle tråder som for tiden utforskes i Project Loom. Den nye planen er en oppfølging av JDK Enhancement Proposal 353 som reimplementerte den eldre Socket API. De nåværende implementeringene avjava.net.datagram.Socketogjava.net.MulticastSocketdateres tilbake til JDK 1.0 og en tid da IPv6 fremdeles var under utvikling. Dermed den nåværende implementeringen avMulticastSocketprøver å forene IPv4 og IPv6 på måter som er vanskelige å vedlikeholde. - Deaktivering av forspent låsing som standard og avvikling av alle relaterte kommandolinjealternativer. Målet er å fastslå behovet for fortsatt støtte for den dyre-å-opprettholde arvssynkroniseringsoptimaliseringen av forspent låsing, som brukes i den virtuelle HotSpot-maskinen for å redusere omkostninger ved uforsvarlig låsing. Selv om enkelte Java-applikasjoner kan se en regresjon i ytelse med forspent låsing deaktivert, er ytelsesgevinsten ved forspent låsing generelt mindre tydelig enn de pleide å være.
- En annen forhåndsvisning av mønstermatching for
tilfelle av, etter en tidligere forhåndsvisning i JDK 14. Mønstertilpasning gjør at vanlig logikk i et program, hovedsakelig betinget utvinning av komponenter fra objekter, kan uttrykkes lettere og kortfattet. Språk som Haskell og C # har tatt imot mønstermatching for sin korthet og sikkerhet. - Skjulte klasser, dvs. klasser som ikke kan brukes direkte av bykoden til andre klasser, er ment for bruk av rammeverk som genererer klasser ved kjøretid, og som bruker dem indirekte gjennom refleksjon. En skjult klasse kan defineres som et medlem av et tilgangskontrollred og kan lastes ut uavhengig av andre klasser. Forslaget vil forbedre effektiviteten til alle språk på JVM ved å gjøre det mulig for en standard API å definere skjulte klasser som ikke er synlige og har en begrenset livssyklus. Rammeverk innenfor og utenfor JDK kunne dynamisk generere klasser som i stedet kunne definere skjulte klasser. Mange språk bygget på JVM er avhengige av dynamisk klassegenerering for fleksibilitet og effektivitet. Målene i dette forslaget inkluderer: å tillate rammer å definere klasser som ikke-oppdagelige implementeringsdetaljer for rammeverket, slik at de ikke kan knyttes mot andre klasser eller oppdages gjennom refleksjon; støtte for å utvide et adgangskontrollnede med ikke-oppdagelige klasser; og støtte for aggressiv lossing av ikke-oppdagelige klasser, så rammer har fleksibilitet til å definere så mange som nødvendig. Et annet mål er å avskaffe ikke-standard API,
misc.Unsafe :: defineAnonymousClass, med den hensikt å avskaffe for fjerning i en fremtidig utgivelse. Java-språket skal heller ikke endres som et resultat av dette forslaget. - Z Garbage Collector (ZGC) uteksamineres fra en eksperimentell funksjon til et produkt under dette forslaget. Integrert i JDK 11, som ankom i september 2018, er ZGC en skalerbar søppeloppsamler med lav latens. ZGC ble introdusert som en eksperimentell evne fordi Java-utviklerne bestemte at en funksjon av denne størrelsen og kompleksiteten skulle bringes inn nøye og gradvis. Siden da har det blitt lagt til en rekke forbedringer, alt fra samtidig klasselasting, frigjøring av ubrukt minne og støtte for deling av klassedata til forbedret NUMA-bevissthet og pre-touching med flere tråder. Dessuten er den maksimale haugestørrelsen økt fra fire terabyte til 16 terabyte. ZGC adresserer ytelsesproblemer i applikasjoner som involverer enorme datamengder, for eksempel maskinlæring, der brukere vil være sikre på at behandling av data ikke vil være utsatt for uforutsigbarhet eller lange pauser på grunn av søppelinnsamling. Plattformer som støttes inkluderer Linux, Windows og MacOS.
- Tekstblokker, forhåndsvist i både JDK 14 og JDK 13, er ment å forenkle oppgaven med å skrive Java-programmer ved å gjøre det enkelt å uttrykke strenger som strekker seg over flere linjer med kildekode, samtidig som man unngår rømningssekvenser i vanlige tilfeller. En tekstblokk er en strenglinje med flere linjer som unngår behovet for de fleste escape-sekvenser, automatisk formaterer strengen på en forutsigbar måte og tilbyr utvikleren kontroll over formatet når det er ønskelig. Et mål med tekstblokkforslaget er å forbedre lesbarheten til strenger i Java-programmer som betegner kode skrevet på ikke-Java-språk. Et annet mål er å støtte migrasjon fra strenglitteraler ved å fastsette at enhver ny konstruksjon kan uttrykke samme sett med strenger som en strenglitteral, tolke de samme rømningssekvensene og bli manipulert på samme måte som en strenglitteral. OpenJDK-utviklerne håper å legge til escape-sekvenser for å administrere eksplisitt hvitt mellomrom og newline-kontroll.
- Shenandoah søppeloppsamler med lav pause, ville bli en produksjonsfunksjon og bevege seg ut av eksperimentet. Den hadde blitt integrert i JDK 12 for et år siden.
- Fjerning av Nashorn, som debuterte i JDK 8 i mars 2014, men har siden blitt gjort foreldet av teknologier som GraalVM. OpenJDK 15-forslaget krever fjerning av Nashorn APIer og jjs-kommandolinjeverktøyet som brukes til å påkalle Nashorn.
- Avvikling av RMI-aktiveringsmekanismen, for fremtidig fjerning. RMI Activation-mekanismen er en foreldet del av RMI som har vært valgfri siden Java 8. RMI Activation pålegger en kontinuerlig vedlikeholdsbyrde. Ingen andre deler av RMI blir avskrevet.
