Produksjonsutgivelsen av Java Development Kit 12, basert på Java SE (Standard Edition) 12, er nå tilgjengelig. JDK 12-builds er tilgjengelige fra Oracle for Linux, Windows og MacOS.
Hvor laster du ned JDK 12
Du kan laste ned JDK 12 fra Java.net-nettstedet.
Open source builds tilbys under GNU General Public License v2, med Classpath Exception. Kommersielle bygg av JDK 12 fra Oracle finnes på Oracle Technology-nettverket under en ikke-åpen kildekode-lisens.
Nye funksjoner i Java 12
Shenandoah søppeloppsamler
Java 12 legger til Shenandoah, en eksperimentell algoritme for innsamling av søppel, for å redusere pausetider for søppelinnsamling ved å utføre evakueringsarbeid samtidig med å kjøre Java-tråder. Shenandoah gir en passende algoritme for applikasjoner som verdsetter respons og forutsigbare korte pauser. Hensikten er imidlertid ikke å fikse alle problemer med JVM-pause.
Red Hat støtter for øyeblikket Shenandoah på Aarch64- og AMD64-arkitekturen.
Avbrytbare blandede samlinger for G1 søppeloppsamleren
Java 12 gjør G1 blandede samlinger avbrutt hvis de kan overskride pausemålet. Målet med G1 var å oppfylle et brukeroppgitt mål for pausetid for samlingspausene.
Tidligere valgte en avansert analysemotor mengden arbeid som skulle gjøres under en samling. Resultatet var et sett med regioner kjent som samlingssettet. Når settet var bestemt og samlingen startet, samlet G1 alle levende gjenstander i regionene til samlingene i alle regioner uten å stoppe. Men dette kan føre til at G1 overskrider pausetidsmålet hvis applikasjonens heuristikker valgte et samlingssett som var for stort.
Det var nødvendig med en mekanisme for å oppdage når heuristikk gjentatte ganger valgte en feil mengde arbeid for samlinger, og hvis dette skjedde, har G1 utført innsamlingsarbeid trinnvis, hvor samlingen kan avbrytes etter hvert trinn. Mekanismen introdusert i Java 12 gjør at G1 kan oppfylle pausetidsmålet oftere.
Rask retur av ubrukt forpliktet minne
Java 12 forbedrer G1 for automatisk å returnere Java heap-minne til operativsystemet når det er inaktiv. Dette minnet frigjøres i en rimelig periode når det er veldig lav applikasjonsaktivitet.
Tidligere returnerte G1 bare minne fra dyngen enten ved full søppeloppsamling eller under en samtidig syklus. Når G1 prøver å unngå full søppeloppsamling, bare utløser en samtidig syklus basert på haugbeleggelse og tildelingsaktivitet, vil den i mange tilfeller ikke returnere haugeminne med mindre den blir tvunget til å gjøre det eksternt. Denne oppførselen var ufordelaktig i containermiljøer der ressurser betales ved bruk. Selv når JVM bare bruker en brøkdel av det tildelte minnet på grunn av inaktivitet, beholdt G1 hele dyngen. Så kundene betalte for alle ressurser hele tiden, og skyleverandører kunne ikke utnytte maskinvaren sin fullt ut.
Med Java 12 kan JVM oppdage faser av haugutnyttelse og automatisk redusere haugbruken i løpet av den tiden.
API for JVM-konstanter
Denne API-en modellerer nominelle beskrivelser av nøkkelklasse-filer og kjøretidsgjenstander, spesielt konstanter som kan lastes fra det konstante bassenget. Java 12 definerer en familie av verdibaserte symbolske referansetyper i en ny pakke, java.lang.invoke.constant, for å beskrive hver type lastbar konstant.
Det er konstante bassenger i alle Java-klasser, og lagrer operander og instruksjoner for bytekode i klassen. Oppføringer i det konstante bassenget beskriver enten gjenstander for kjøretid som klasser og metoder eller enkle verdier som strenger og heltall. Disse oppføringene er kjent som lastbare konstanter.
Programmer som manipulerer klassefiler, må modellere bytekodeinstruksjoner og i sin tur lastbare konstanter. Men å bruke standard Java-typer for å modellere lastbare konstanter er utilstrekkelig. Dette kan være akseptabelt for en lastbar konstant som beskriver en streng, men det er problematisk for en lastbar konstant som beskriver en klasse, fordi det å produsere en "live" Klasse objektet er avhengig av korrektheten og konsistensen av klasselasting. Klasselasting har imidlertid mange miljøavhengigheter og feilmodus.
Så, programmer som håndterer lastbare konstanter, kan forenkles hvis de kan manipulere klasser og metoder og mindre kjente gjenstander som metodeshåndtak og dynamisk beregnede konstanter i en nominell, symbolsk form. Dermed gir JVM konstanter API biblioteker og verktøy en enkelt, standard måte å beskrive lastbare konstanter på.
Forbedret oppstart, CDS og søppelinnsamling
Java 12 forbedrer JDK-byggeprosessen for å generere et standard klassedatadeling (CDS) arkiv, ved hjelp av standard klasseliste, på 64-biters plattformer. Dette forbedrer oppstartstiden og eliminerer behovet for å løpe -Xshare: dump for å dra nytte av CDS. JDK-byggeprosessen er endret for å kjøre java-xshare: dump etter å ha koblet bildet.
Ytterligere kommandolinjealternativer har blitt inkludert for å finjustere søppeltømmingstiden for å forbedre minneoppsettet for vanlige saker. Brukere med mer avanserte krav, som for eksempel tilpassede klasselister som inkluderer applikasjonsklasser og forskjellige søppeloppsamlingskonfigurasjoner, er fremdeles i stand til å lage et tilpasset CDS-arkiv.
Redusert antall ARM-porter
Java 12 fjerner alle kilder relatert til arm64 port mens du beholder 32-biters ARM og 64-bit aarch64. Fjerning av denne porten vil la bidragsytere fokusere innsatsen på en enkelt 64-bit ARM-implementering og eliminere duplikatarbeid som vil være resultatet av å opprettholde to porter. Foreløpig er to 64-biters ARM-porter i JDK.
Bytt uttrykk
Bryteruttrykk forenkler koding ved å utvide bytte om uttalelse slik at den kan brukes som enten en uttalelse eller et uttrykk. Dette gjør at både utsagn og uttrykk kan bruke enten “tradisjonell” eller “forenklet” avgrensnings- og kontrollflytadferd. Disse endringene resulterer i enklere "hverdags" koding og forbereder veien for bruk av mønstermatching i bytte om.
Når Java-byggere beveger seg for å støtte mønstermatching, uregelmessigheter i Javabytte om uttalelse har blitt hindringer. Disse inkluderer standard strømningsoppførsel for bryterblokker; standard scoping av bryterblokker, der blokken behandles som ett enkelt omfang; og bytte fungerer bare som en uttalelse. Den nåværende utformingen av Java’s bytte om uttalelse følger nøye med språk som C ++ og støtter som standard gjennombruddsemantikk. Denne kontrollflyten har vært nyttig for å skrive kode på lavt nivå. Men når bryteren brukes i høyere nivåer, begynner dens feilutsatte natur å oppveie fleksibiliteten.
Grunnleggende referansesuite
JDK 12 inkluderer en grunnleggende pakke med mikrobenker, som er lagt til plattformens kildekode. Målet er å gjøre det lettere for utviklere å kjøre eksisterende referanser eller bygge nye.
Forslaget om mikrobenchmarkspakke, opprettet i juli 2014 og oppdatert tidlig i november 2018, ble understøttet av Java Microbenchmark Harness (JMH), for å bygge referanser som er skrevet på Java og andre JVM-språk. Suiten er samlokalisert med JDK-kildekode i en enkelt katalog, med utviklere som enkelt kan legge til nye referanser.
Det var ikke et mål å gi referanser for nye JDK-funksjoner eller lage et komplett sett med referanser som dekker alt i JDK. Vær også oppmerksom på at benchmarking-pakken ikke er nødvendig for vanlige JDK-bygg, men er et eget byggemål.
I forslaget ble det opprettet en ny side på wiki.openjdk.java.net for å forklare hvordan man kan utvikle referanser og beskrive krav. Disse kravene vil kreve overholdelse av kodestandarder, reproduserbar ytelse og dokumentasjon.
JDK 12 oppdateringer
Planene krever at JDK 12 skal motta to oppdateringer før de blir etterfulgt av JDK 13 om seks måneder. JDK 12 er en del av Oracles seks måneders utgivelseskadens introdusert med JDK 9 i september 2017. JDK 12 karakteriseres som en funksjonsutgivelse, i motsetning til JDK 11, som er en langsiktig supportutgivelse med flere års støtte planlagt.
