JDK 12: De nya funktionerna i Java 12

Produktionsversionen av Java Development Kit 12, baserad på Java SE (Standard Edition) 12, är nu tillgänglig. JDK 12-byggnader är tillgängliga från Oracle för Linux, Windows och MacOS. 

Var kan jag ladda ner JDK 12

Du kan ladda ner JDK 12 från Java.net-webbplatsen.

Öppen källkodsbyggnad tillhandahålls under GNU General Public License v2, med Classpath Exception. Kommersiella byggnader av JDK 12 från Oracle finns i Oracle Technology-nätverket under en licens som inte är öppen källkod.

Nya funktioner i Java 12

Shenandoah sopor

Java 12 lägger till Shenandoah, en experimentell skräpsamlingsalgoritm, för att minska paustiderna för skräpsamling genom att utföra evakueringsarbete samtidigt med Java-trådar. Shenandoah tillhandahåller en lämplig algoritm för applikationer som värdesätter respons och förutsägbara korta pauser. Avsikten är dock inte att åtgärda alla JVM-pausproblem.

Red Hat stöder för närvarande Shenandoah på Aarch64- och AMD64-arkitekturen.

Avbrytbara blandade samlingar för G1-sopor

Java 12 gör att blandade G1-samlingar avbryts om de kan överskrida pausmålet. Ett mål för G1 var att uppfylla ett användartillhandahållet paustidsmål för dess samlingspauser.

Tidigare valde en avancerad analysmotor hur mycket arbete som ska utföras under en samling. Resultatet blev en uppsättning regioner som kallas samlingsuppsättningen. När uppsättningen hade bestämts och samlingen startade samlade G1 alla levande objekt i regionerna i samlingarna i alla regioner utan att stoppa. Men detta kan leda till att G1 överskrider paustidens mål om en applikations heuristik väljer en för stor uppsamlingsuppsättning.

Det behövdes en mekanism för att upptäcka när heuristik upprepade gånger valt en felaktig mängd arbete för samlingar och, om detta hände, har G1 utför samlingsarbete stegvis i steg, där samlingen kunde avbrytas efter varje steg. Mekanismen som introducerades i Java 12 gör att G1 kan möta paustidens mål oftare.

Snabb återlämnande av oanvänt minne

Java 12 förbättrar G1 för att automatiskt returnera Java-heapminne till operativsystemet när det är inaktivt. Det här minnet släpps under en rimlig tidsperiod när det finns mycket låg applikationsaktivitet.

Tidigare returnerade G1 bara minne från högen antingen vid en fullständig skräpsamling eller under en samtidig cykel. När G1 försöker undvika full skräpsamling, bara utlöser en samtidig cykel baserad på högbeläggning och allokeringsaktivitet, skulle den i många fall inte returnera högminne om den inte tvingas göra det externt. Detta beteende var ofördelaktigt i containermiljöer där resurser betalas genom användning. Även när JVM bara använder en bråkdel av sitt tilldelade minne på grund av inaktivitet behöll G1 hela högen. Så kunder betalade för alla resurser hela tiden och molnleverantörer kunde inte utnyttja sin hårdvara till fullo.

Med Java 12 kan JVM upptäcka faser av högutnyttjande och automatiskt minska sin höganvändning under den tiden. 

API för JVM-konstanter

Detta API modellerar nominella beskrivningar av nyckelklassfiler och runtime-artefakter, särskilt konstanter som kan laddas från den konstanta poolen. Java 12 definierar en familj av värdebaserade symboliska referenstyper i ett nytt paket java.lang.invoke.constant, för att beskriva varje typ av laddbar konstant.

Konstanta pooler finns i alla Java-klasser och lagrar operander och bytkodinstruktioner i klassen. Inmatningar i den konstanta poolen beskriver antingen runtime-artefakter som klasser och metoder eller enkla värden som strängar och heltal. Dessa poster är kända som lastbara konstanter.

Program som manipulerar klassfiler måste modellera bytkodinstruktioner och i sin tur laddningsbara konstanter. Men att använda vanliga Java-typer för att modellera laddningsbara konstanter är otillräckligt. Detta kan vara acceptabelt för en lastbar konstant som beskriver en sträng, men det är problematiskt för en lastbar konstant som beskriver en klass, eftersom att producera ett "live" Class-objekt är beroende av riktigheten och konsistensen av klassbelastningen. Klassbelastning har dock många miljöberoenden och fellägen.

Så program som hanterar laddningsbara konstanter kan förenklas om de kan manipulera klasser och metoder och mindre kända artefakter som metodhandtag och dynamiskt beräknade konstanter i en nominell symbolisk form. Således ger JVM konstanter API bibliotek och verktyg ett enda, standardiserat sätt att beskriva laddningsbara konstanter.

Förbättrad start-, CDS- och skräpsamling

Java 12 förbättrar JDK-byggprocessen för att generera ett CDS-arkiv (standard klassdelningsdata) med standardklasslistan på 64-bitars plattformar. Detta förbättrar out-of-the-box starttid och eliminerar behovet av att köra för -Xshare:dumpatt dra nytta av CDS. JDK-byggprocessen har modifierats för att köras java-xshare:dumpefter att bilden har länkats.

Ytterligare kommandoradsalternativ har inkluderats för att finjustera skräpuppsamlingstider för att förbättra minneslayouten för vanliga fall. Användare med mer avancerade krav, som anpassade klasslistor som inkluderar applikationsklasser och olika konfigurationer för skräpsamling, kan fortfarande skapa ett anpassat CDS-arkiv.

Minskat antal ARM-portar

Java 12 tar bort alla källor relaterade till arm64porten samtidigt som 32-bitars ARM och 64-bit behålls aarch64. Borttagning av denna port skulle låta bidragsgivarna fokusera ansträngningarna på en enda 64-bitars ARM-implementering och eliminera duplicerat arbete som skulle bli resultatet av att två portar upprätthålls. För närvarande finns två 64-bitars ARM-portar i JDK.

Byt uttryck

Växlingsuttryck förenklar kodning genom att utöka switchuttalandet så att det kan användas antingen som ett uttalande eller ett uttryck. Detta gör att både uttalanden och uttryck kan använda antingen "traditionell" eller "förenklad" scoping- och kontrollflödesbeteende. Dessa förändringar resulterar i enklare "vardaglig" kodning och förbereder vägen för användning av mönstermatchning i switch.

När Java-byggare flyttar för att stödja mönstermatchning har oegentligheter i Java-  switchuttalandet blivit hinder. Dessa inkluderar standardkontrollflödesbeteendet för växelblock; standardomfattning av växelblock, där blocket behandlas som ett enda omfång; och växla fungerar endast som ett uttalande. Den nuvarande utformningen av Javas switchuttalande följer noggrant språk som C ++ och stöder som standard genomgående semantik. Detta kontrollflöde har varit användbart för att skriva lågnivåkod. Men när switch används i högre sammanhang börjar dess felbenägna natur att uppväga flexibiliteten.

Grundläggande riktmärkesvit

JDK 12 innehåller en grundläggande svit av mikrobenchmarks, som har lagts till plattformens källkod. Målet är att göra det lättare för utvecklare att köra befintliga riktmärken eller bygga nya.

Microbenchmarks-svitförslaget, skapat i juli 2014 och uppdaterat i början av november 2018, stöddes av Java Microbenchmark Harness (JMH) för att bygga riktmärken skrivna på Java och andra JVM-språk. Sviten samlas med JDK-källkod i en enda katalog, där utvecklare enkelt kan lägga till nya riktmärken.

Det var inte ett mål att tillhandahålla riktmärken för nya JDK-funktioner eller skapa en komplett uppsättning riktmärken som täcker allt i JDK. Observera också att benchmarking-sviten inte krävs för vanliga JDK-byggnader utan är ett separat byggmål. 

Förslaget krävde att en ny sida skulle skapas på wiki.openjdk.java.net för att förklara hur man kan utveckla riktmärken och beskriva krav. Dessa krav kräver att kodningsstandarder, reproducerbar prestanda och dokumentation följs.

JDK 12 uppdateringar

Planer kräver att JDK 12 ska få två uppdateringar innan de efterföljs av JDK 13 på sex månader. JDK 12 är en del av Oracles sex-månaders release-kadens som introducerades med JDK 9 i september 2017. JDK 12 karaktäriseras som en funktionsrelease, till skillnad från JDK 11, som är en långvarig supportrelease med flera års stöd planerat.