Produktionsudgivelsen af Java Development Kit 12, baseret på Java SE (Standard Edition) 12, er nu tilgængelig. JDK 12-builds er tilgængelige fra Oracle til Linux, Windows og MacOS.
Hvor downloades JDK 12
Du kan downloade JDK 12 fra Java.net-webstedet.
Open source-builds leveres under GNU General Public License v2 med Classpath Exception. Kommercielle builds af JDK 12 fra Oracle kan findes på Oracle Technology-netværket under en ikke-open source-licens.
Nye funktioner i Java 12
Shenandoah affaldssamler
Java 12 tilføjer Shenandoah, en eksperimentel algoritme til indsamling af affald, for at reducere pausetider for affaldssamling ved at udføre evakueringsarbejde samtidig med at Java-tråde køres. Shenandoah giver en passende algoritme til applikationer, der værdsætter respons og forudsigelige korte pauser. Hensigten er dog ikke at løse alle problemer med JVM-pause.
Red Hat understøtter i øjeblikket Shenandoah på Aarch64 og AMD64 arkitekturer.
Aborterbare blandede samlinger til G1 affaldssamleren
Java 12 gør G1 blandede samlinger afbrudte, hvis de måske overskrider pausemålet. Et mål for G1 var at opfylde et brugerleveret mål for pausetid for dets indsamlingspauser.
Tidligere valgte en avanceret analysemaskine, hvor meget arbejde der skulle udføres under en samling. Resultatet var et sæt regioner kendt som samlingssættet. Når sættet var bestemt og indsamlingen startede, samlede G1 alle levende objekter i regionerne i samlingerne i alle regioner uden at stoppe. Men dette kan føre til, at G1 overskrider pausetidsmålet, hvis en applikations heuristik valgte et samlingssæt, der var for stort.
En mekanisme var nødvendig for at opdage, når heuristik gentagne gange valgte en forkert mængde arbejde til samlinger, og hvis dette skete, har G1 udført indsamlingsarbejde trinvist i trin, hvor samlingen kunne afbrydes efter hvert trin. Mekanismen, der blev introduceret i Java 12, gør det muligt for G1 at nå målet om pausetid oftere.
Hurtig returnering af ubrugt hukommelse
Java 12 forbedrer G1 til automatisk at returnere Java bunkehukommelse til operativsystemet, når det er inaktiv. Denne hukommelse frigives i en rimelig periode, når der er meget lav applikationsaktivitet.
Tidligere returnerede G1 kun hukommelse fra bunken ved enten en fuld affaldssamling eller under en samtidig cyklus. Når G1 forsøger at undgå fuld affaldsindsamling, der kun udløser en samtidig cyklus baseret på bunkebelægning og tildelingsaktivitet, ville den i mange tilfælde ikke returnere bunkehukommelse, medmindre den bliver tvunget til at gøre det eksternt. Denne adfærd var ufordelagtig i containermiljøer, hvor ressourcer betales ved brug. Selv når JVM kun bruger en brøkdel af sin tildelte hukommelse på grund af inaktivitet, bevarede G1 den fulde bunke. Så kunder betalte for alle ressourcer hele tiden, og cloud-udbydere kunne ikke udnytte deres hardware fuldt ud.
Med Java 12 kan JVM registrere faser af bunkeunderudnyttelse og automatisk reducere dens bunkebrug i løbet af denne tid.
API til JVM-konstanter
Denne API modellerer nominelle beskrivelser af nøgleklassefiler og runtime-artefakter, især konstanter, der kan indlæses fra den konstante pool. Java 12 definerer en familie af værdibaserede symbolske referencetyper i en ny pakke, java.lang.invoke.constant, for at beskrive hver type belastbar konstant.
Der findes konstante puljer i alle Java-klasser, der gemmer operander og bytecode-instruktioner i klassen. Indgange i den konstante pool beskriver enten runtime-artefakter såsom klasser og metoder eller enkle værdier såsom strenge og heltal. Disse poster er kendt som belastbare konstanter.
Programmer, der manipulerer klassefiler, skal modelere bytecode-instruktioner og til gengæld konstanter, der kan indlæses. Men at bruge standard Java-typer til at modellere belastbare konstanter er utilstrækkelig. Dette kan være acceptabelt for en belastbar konstant, der beskriver en streng, men det er problematisk for en belastbar konstant, der beskriver en klasse, fordi der produceres en "live" Klasse objekt er afhængig af rigtigheden og konsistensen af klasseindlæsning. Klassebelastning har dog mange miljøafhængigheder og fejltilstande.
Så programmer, der beskæftiger sig med konstater, der kan indlæses, kunne forenkles, hvis de kunne manipulere klasser og metoder og mindre kendte artefakter såsom metodeshåndtag og dynamisk beregnede konstanter i en nominel, symbolsk form. Således giver JVM konstanter API biblioteker og værktøjer en enkelt, standard måde at beskrive indlæselige konstanter på.
Forbedret opstart, CDS og affaldsindsamling
Java 12 forbedrer JDK-byggeprocessen til at generere et CDS-arkiv (standard klassedatadeling) ved hjælp af standardklasselisten på 64-bit platforme. Dette forbedrer opstartstiden uden for boksen og eliminerer behovet for at køre -Xshare: dump at drage fordel af CDS. JDK-byggeprocessen er blevet ændret til at køre java-xshare: dump efter at have linket billedet.
Yderligere kommandolinjemuligheder er inkluderet for at finjustere bunktider til affaldsindsamling for at forbedre hukommelseslayoutet til almindelige sager. Brugere med mere avancerede krav, såsom brugerdefinerede klasselister, der inkluderer applikationsklasser og forskellige affaldssamlingskonfigurationer, er stadig i stand til at oprette et brugerdefineret CDS-arkiv.
Reduceret antal ARM-porte
Java 12 fjerner alle kilder relateret til arm64 port, mens 32-bit ARM og 64-bit bevares aarch64. Fjernelse af denne port vil lade bidragsydere fokusere bestræbelserne på en enkelt 64-bit ARM-implementering og eliminere dobbeltarbejde, der ville være resultatet af vedligeholdelse af to porte. I øjeblikket er der to 64-bit ARM-porte i JDK.
Skift udtryk
Switch-udtryk forenkler kodning ved at udvide kontakt sætning, så den kan bruges som enten en sætning eller et udtryk. Dette gør det muligt for både udsagn og udtryk at bruge enten "traditionel" eller "forenklet" scoping- og kontrolflowadfærd. Disse ændringer resulterer i enklere "hverdagskodning" og forbereder vejen til brug af mønstertilpasning i kontakt.
Når Java-bygherrer bevæger sig for at understøtte mønstermatchning, uregelmæssigheder i Javakontakt udsagn er blevet hindringer. Disse inkluderer standardkontrolflowadfærd for switchblokke; standard scoping af switch blokke, hvor blokken behandles som et enkelt omfang; og skifte fungerer kun som en erklæring. Det aktuelle Java-design kontakt erklæring følger nøje sprog som C ++ og understøtter som standard gennembrudssemantik. Dette kontrolflow har været nyttigt til at skrive kode på lavt niveau. Men når switch bruges i højere sammenhænge, begynder dens fejltagende natur at opveje fleksibiliteten.
Grundlæggende benchmark-suite
JDK 12 inkluderer en grundlæggende pakke med mikrobenchmarks, der er blevet føjet til platformens kildekode. Målet er at gøre det lettere for udviklere at køre eksisterende benchmarks eller opbygge nye.
Forslaget om mikrobenchmarks-pakken, oprettet i juli 2014 og opdateret i begyndelsen af november 2018, blev understøttet af Java Microbenchmark Harness (JMH) til opbygning af benchmarks skrevet på Java og andre JVM-sprog. Suiten er samlokaliseret med JDK-kildekode i en enkelt mappe, hvor udviklere nemt kan tilføje nye benchmarks.
Det var ikke et mål at give benchmarks til nye JDK-funktioner eller oprette et komplet sæt benchmarks, der dækker alt i JDK. Bemærk også, at benchmarking-pakken ikke er påkrævet for regelmæssige JDK-builds, men er et separat build-mål.
Forslaget opfordrede til oprettelse af en ny side på wiki.openjdk.java.net for at forklare, hvordan man udvikler benchmarks og beskriver krav. Disse krav vil kræve overholdelse af kodningsstandarder, reproducerbar ydeevne og dokumentation.
JDK 12 opdateringer
Planer kræver, at JDK 12 modtager to opdateringer, inden de efterfølges af JDK 13 om seks måneder. JDK 12 er en del af Oracles seks måneders frigivelseskadence introduceret med JDK 9 i september 2017. JDK 12 er karakteriseret som en funktionsudgivelse i modsætning til JDK 11, som er en langsigtet supportudgivelse med flere års planlagt support.
