Java Development Kit (JDK) 16 har nådd sin innledende rampdown-fase, noe som betyr at funksjonssettet nå er frossent fra 10. desember 2020. De nye funksjonene i JDK 16 spenner fra en annen forhåndsvisning av forseglede klasser til mønstermatching til samtidig tråd- stabelbehandling for søppeloppsamling.
JDK 16 vil være referanseimplementeringen av versjonen av standard Java som følger JDK 15, som ankom 15. september. En foreslått utgivelsesplan har at JDK 16 når en andre nedtrappingsfase 14. januar 2021, etterfulgt av utgivelseskandidater som ankommer 4. februar og 18. februar 2021. Produksjonsutgivelsen er planlagt å bli publisert 16. mars 2021.
Sytten forslag er offisielt rettet mot JDK 16 fra 10. desember 2020. De nye mulighetene som kommer til Java 16 inkluderer:
- Advarslene for verdibaserte klasseforslag betegner de primitive innpakningsklassene som verdibaserte og avskaffer deres konstruktører for fjerning, og ber om nye advarsler om avskrivning. Advarsler gis om uriktige forsøk på å synkronisere forekomster av verdibaserte klasser i Java-plattformen. Å drive denne innsatsen er Valhalla-prosjektet, som forfølger en betydelig forbedring av Java-programmeringsmodellen i form av primitive klasser. Primitive klasser erklærer forekomster som identitetsfrie og i stand til innebygde eller flate representasjoner, der forekomster kan kopieres fritt mellom minneplasser og kodes ved hjelp av verdier av forekomstenes felt. Utformingen og implementeringen av primitive klasser i Java er nå tilstrekkelig moden til at migrering av visse klasser av Java-plattformen til primitive klasser kan forventes i en fremtidig utgivelse. Kandidater for migrasjon blir uformelt utpekt som verdibaserte klasser i API-spesifikasjoner.
- Tidligere forhåndsvist i JDK 15 begrenser forseglede klasser og grensesnitt hvilke andre klasser og grensesnitt som kan utvide eller implementere dem. Målene i planen inkluderer å tillate forfatteren av en klasse eller et grensesnitt å kontrollere koden 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 å gi et grunnlag for analyse av mønstre.
- Sterk innkapsling av JDK-interner som standard, bortsett fra kritiske interne API-er som
misc. usikkert. Brukere kan velge den avslappede sterke innkapslingen som har vært standard siden JDK 9. Målene i dette forslaget inkluderer forbedring av sikkerheten og vedlikeholdsevnen til JDK, som en del av Project Jigsaw, og oppfordring til utviklere til å migrere fra å bruke interne elementer til å bruke standard APIer, slik at at både utviklere og sluttbrukere enkelt kan oppdatere til fremtidige Java-utgivelser. Dette forslaget bærer en primær risiko for at eksisterende Java-kode ikke kan kjøres. Utviklere oppfordres til å bruke jdeps-verktøyet til å identifisere kode som avhenger av interne elementer i JDK og bytte til standard erstatninger når tilgjengelig. Utviklere kan bruke en eksisterende utgivelse, for eksempel JDK 11, for å teste eksisterende kode ved hjelp av--illegal-access = advareå identifisere interne elementer som er tilgjengelig via refleksjon, ved hjelp av--illegal-access = feilsøkingfor å finne feilkode, og teste med--illegal-access = nekte. - Utenlandsk linker API, som tilbyr statisk skrevet, ren Java-tilgang til innfødt kode. Denne API-en vil være i et inkubatorstadium i JDK 16. Sammen med den foreslåtte API-et for fremmedminnetilgang vil den utenlandske linker-APIen betydelig forenkle den ellers feilutsatte prosessen med å binde til et eget bibliotek. Denne planen er ment å erstatte JNI (Java Native Interface) med en overlegen ren Java-utviklingsmodell, for å tilby C-støtte, og over tid være fleksibel nok til å imøtekomme støtte for andre plattformer, for eksempel 32-biters x86, og utenlandske funksjoner skrevet på andre språk enn C, for eksempel C ++. Ytelsen skal være bedre enn eller sammenlignbar med JNI.
- Flytter ZGC (Z Garbage Collector) trådstabelbehandling fra safepoints til en samtidig fase. Målene i denne planen inkluderer fjerning av trådstabelbehandling fra ZGC safepoints; gjør stabelbehandling lat, samarbeidsvillig, samtidig og inkrementell; fjerning av all annen rotbehandling av tråder fra ZGC safepoints; og sørge for en mekanisme for andre HotSpot VM-delsystemer for å behandle stabler på en lat måte. ZGC er ment å gjøre GC-pauser og skalerbarhetsproblemer i HotSpot til en fortid. Så langt har GC-operasjoner som skalerer seg med haugens størrelse og størrelsen på metaspace blitt flyttet ut av safepoint-operasjoner og til samtidige faser. Disse har inkludert merking, flytting, referansebehandling, klasselasting og mest rotbehandling. De eneste aktivitetene som fortsatt gjøres i GC-safepoints er en delmengde av rotbehandling og en tidsavgrenset avslutning. Disse røttene har inkludert Java-trådstabler og andre trådrøtter, og disse røttene er problematiske fordi de skalerer med antall tråder. For å gå utover den nåværende situasjonen, må prosessering per tråd, inkludert stableskanning, flyttes til en samtidig fase. Med denne planen bør gjennomstrømningskostnadene for den forbedrede ventetiden være ubetydelig, og tiden brukt i ZGC-safepoeng på typiske maskiner bør være mindre enn ett millisekund.
- En elastisk metaspace-funksjon, som returnerer ubrukt HotSpot VM-klasse metadata (metaspace) -minne raskere til operativsystemet, reduserer metaspace footprint og forenkler metaspace-koden for å redusere vedlikeholdskostnadene. Metaspace har hatt problemer med høy bruk av minne utenfor heapen. Planen krever at man erstatter den eksisterende minnetildelingen med en kompisbasert tildelingsplan, og gir en algoritme for å dele minne i partisjoner for å tilfredsstille minneforespørsler. Denne tilnærmingen har blitt brukt på steder som Linux-kjernen, og vil gjøre det praktisk å tildele minne i mindre biter for å redusere overbelastning av klasselaster. Fragmentering vil også bli redusert. I tillegg vil minnet fra operativsystemet til minnestyringsarenaene gjøres lat, på forespørsel, for å redusere fotavtrykket for lastere som starter med store arenaer, men som ikke bruker dem umiddelbart eller kanskje ikke bruker dem i full grad. For å utnytte elastisiteten som kompisallokering gir full nytte, vil metaspace-minne ordnes i ensartede granulater som kan være forpliktet og uforpliktende uavhengig av hverandre.
- Aktivering av C ++ 14 språkfunksjoner, for å tillate bruk av C ++ 14-funksjoner i JDK C ++ kildekode og gi spesifikk veiledning om hvilke av disse funksjonene som kan brukes i HotSpot VM-kode. Gjennom JDK 15 har språkfunksjonene som brukes av C ++ - koden i JDK vært begrenset til C ++ 98/03 språkstandarder. Med JDK 11 ble kildekoden oppdatert for å støtte bygging med nyere versjoner av C ++ - standarden. Dette inkluderer å kunne bygge med nyere versjoner av kompilatorer som støtter C ++ 11/14 språkfunksjoner. Dette forslaget foreslår ingen endringer i stil eller bruk for C ++ - kode som brukes utenfor HotSpot. Men for å dra nytte av C ++ språkfunksjoner, kreves det noen endringer i byggetiden, avhengig av plattformkompilatoren.
- En vektor-API i et inkubatorstadium der JDK vil bli utstyrt med en inkubator-modul,
jdk.incubator.vector, for å uttrykke vektorberegninger som kompilerer til optimale maskinvareanvisninger for vektorer om støttede CPU-arkitekturer, for å oppnå overlegen ytelse til tilsvarende skalarberegninger. Vector API gir en mekanisme for å skrive komplekse vektoralgoritmer i Java, ved å bruke eksisterende støtte i HotSpot VM for vektorisering, men med en brukermodell som gjør vektorisering mer forutsigbar og robust. Målet med forslaget inkluderer å tilby en klar og kort API for å uttrykke en rekke vektorberegninger, være plattform-agnostisk ved å støtte flere CPU-arkitekturer, og tilby pålitelig kjøretidskompilering og ytelse på x64- og AArch64-arkitekturer. Grasiøs nedbrytning er også et mål der en vektorberegning vil forringes elegant og fremdeles fungerer hvis den ikke kan uttrykkes fullstendig ved kjøretid som en sekvens av maskinvarevektorinstruksjoner, enten fordi en arkitektur ikke støtter noen instruksjoner eller annen CPU-arkitektur ikke støttes . - Portering av JDK til Windows / AArch64-plattformen. Med lanseringen av ny serverklasse og forbruker AArch64 (ARM64) maskinvare har Windows / AArch64 blitt en viktig plattform på grunn av etterspørsel. Mens selve porteringen allerede er for det meste fullført, innebærer fokuset i dette forslaget integrering av porten i hovedlinjen JDK repository.
- Portering av JDK til Alpine Linux og til andre Linux-distribusjoner som bruker musl som deres primære C-bibliotek, på x64- og AArch64-arkitekturer. Musl er en Linux-implementering av standardbibliotekets funksjonalitet beskrevet i ISO C- og Posix-standardene. Alpine Linux er mye brukt i skyinstallasjoner, mikrotjenester og containermiljøer på grunn av den lille bildestørrelsen. Et Docker-bilde for Linux er mindre enn 6 MB. Hvis du lar Java kjøre ut av boksen i slike innstillinger, kan Tomcat, Jetty, Spring og andre populære rammer fungere naturlig i disse miljøene. Ved å bruke jlink for å redusere størrelsen på Java-kjøretiden, kan en bruker opprette et enda mindre bilde skreddersydd for å kjøre et bestemt program.
- Tilby postklasser som fungerer som gjennomsiktige bærere for uforanderlige data. Rekorder kan betraktes som nominelle tupler. Rekordene ble forhåndsvist i JDK 14 og JDK 15. Denne innsatsen er som svar på klager på at Java har vært for ordentlig eller har for mye seremoni. Målene i planen inkluderer utforming av en objektorientert konstruksjon som uttrykker en enkel aggregering av verdier, og hjelper utviklere å fokusere på modellering av uforanderlige data i stedet for utvidbar oppførsel, og implementerer automatisk datadrevne metoder som
er likog tilbehør, og bevare langvarige Java-prinsipper som nominell skriving. - Tillegg av Unix-domene sokkelkanaler, der Unix-domenes (AF_UNIX) sokkelstøtte legges til sokkelkanalen og serveruttakskanal-API-ene i nio.channels-pakken. Planen utvider også den arvede kanalmekanismen til å støtte Unix-domene sokkelkanaler og serveruttakskanaler. Unix-domenekontakter brukes til kommunikasjon mellom prosesser på samme vert. De ligner på TCP / IP-kontakter i de fleste henseender, bortsett fra at de adresseres av filsystembanenavn i stedet for IP-adresser og portnumre. Målet med den nye funksjonen er å støtte alle funksjonene i Unix-domene-sokkelkanaler som er vanlige på store Unix-plattformer og Windows. Unix-domenekontaktkanaler vil oppføre seg på samme måte som eksisterende TCP / IP-kanaler når det gjelder lese / skrive-oppførsel, tilkoblingsoppsett, aksept av innkommende tilkoblinger av servere og multiplexing med andre ikke-blokkerende valgbare kanaler i en velger. Unix-domenekontakter er sikrere og mer effektive enn TCP / IP loopback-tilkoblinger for lokal kommunikasjon mellom prosesser.
- En API for fremmedminnetilgang, slik at Java-programmer trygt kan få tilgang til utenlandsk minne utenfor Java-bunken. Tidligere inkubert i både JDK 14 og JDK 15, ville API-et for fremmedminnetilgang bli inkubert i JDK 16, og legge til forbedringer. Endringer er gjort, inkludert en klarere skillet mellom roller mellom
MemorySegmentogMemoryAdressesgrensesnitt. Målene for dette forslaget inkluderer å tilby en enkelt API for å operere på forskjellige typer fremmed minne, inkludert innfødt, vedvarende og administrert dyngminne. API-et bør ikke undergrave sikkerheten til JVM. Motiverende forslaget er at mange Java-programmer får tilgang til fremmed minne, som Ignite, Memcached og MapDB. Men Java API gir ikke en tilfredsstillende løsning for tilgang til fremmed minne. - Mønster matching for
tilfelle avoperatør, som også ble forhåndsvist i både JDK 14 og JDK 15. Det ville bli avsluttet i JDK 16. Mønstermatching gjør at vanlig logikk i et program, nemlig betinget utvinning av komponenter fra objekter, kan uttrykkes mer kortfattet og sikkert. - Tilby jpackage-verktøyet for pakking av selvstendige Java-applikasjoner. Introdusert som et inkubasjonsverktøy i JDK 14, forble jpackage i inkubasjon i JDK 15. Med JDK 16 går jpackage til produksjon, og støtter innfødte pakkeformater for å gi brukerne en naturlig installasjonsopplevelse og tillate at starttidsparametere blir spesifisert på emballasje. Formater inkluderer msi og exe på Windows, pkg og dmg på MacOS, og deb og rpm på Linux. Verktøyet kan påberopes direkte fra kommandolinjen eller programmatisk. Det nye emballeringsverktøyet adresserer en situasjon der mange Java-applikasjoner må installeres på innfødte plattformer på en førsteklasses måte, i stedet for å bli plassert på klassebanen eller modulbanen. Det er behov for en installerbar pakke som passer for den opprinnelige plattformen.
- Migrering av OpenJDK kildekodelager fra Mercurial til Git. Å drive denne innsatsen er fordeler i versjonskontrollsystemets metadatastørrelse og tilgjengelige verktøy og hosting.
- Migrasjon til GitHub, relatert til Mercurial-to-Git-migreringen, med JDK 16 kildekodelager for å være på det populære kodedelingsnettstedet. JDK-funksjonsutgivelser og JDK-oppdateringsutgivelser for Java 11 og senere vil være en del av denne planen. Overgangen til Git, GitHub og Skara for Mercurial JDK og JDK-sandkassen ble gjort 5. september og er åpen for bidrag.
Tidlig tilgangsbygging av JDK 16 for Linux, Windows og MacOS finner du på jdk.java.net. I likhet med JDK 15 vil JDK 16 være en kortsiktig utgivelse, støttet i seks måneder. JDK 17, som forfaller i september 2021, vil være en langsiktig støtteutgivelse (LTS) som vil motta flere års støtte. Den nåværende LTS-utgivelsen, JDK 11, ble utgitt i september 2018.
