Java Development Kit (JDK) 16 har nået sin indledende rampdown-fase, hvilket betyder, at funktionssættet nu er frosset pr. 10. december 2020. De nye funktioner i JDK 16 spænder fra en anden forhåndsvisning af forseglede klasser til mønstermatchning til samtidig tråd- stakbehandling til affaldsindsamling.
JDK 16 vil være referenceimplementeringen af den version af standard Java, der følger JDK 15, som ankom 15. september. I en foreslået frigivelsesplan er JDK 16 nået til en anden rampdown-fase den 14. januar 2021 efterfulgt af frigivelseskandidater, der ankommer 4. februar og 18. februar 2021. Produktionsudgivelsen forventes offentliggjort 16. marts 2021.
Sytten forslag er officielt rettet mod JDK 16 fra den 10. december 2020. De nye muligheder, der kommer til Java 16, inkluderer:
- Advarslerne for værdibaserede klasseforslag angiver de primitive indpakningsklasser som værdibaserede og fraråder deres konstruktører til fjernelse, hvilket medfører nye advarsler om afskrivning. Advarsler gives om forkert forsøg på at synkronisere i tilfælde af værdibaserede klasser i Java-platformen. At drive denne indsats er Valhalla-projektet, der forfølger en betydelig forbedring af Java-programmeringsmodellen i form af primitive klasser. Primitive klasser erklærer forekomster for at være identitetsfrie og i stand til indlejrede eller flade repræsentationer, hvor forekomster kan kopieres frit mellem hukommelsesplaceringer og kodes ved hjælp af værdier for forekomster. Designet og implementeringen af primitive klasser i Java er nu tilstrækkeligt modent til, at migrationen af visse klasser af Java-platformen til primitive klasser kan forventes i en fremtidig frigivelse. Kandidater til migration er uformelt udpeget som værdibaserede klasser i API-specifikationer.
- Tidligere vist i JDK 15 begrænser forseglede klasser og grænseflader, hvilke andre klasser og grænseflader, der kan udvide eller implementere dem. Planens mål inkluderer at tillade forfatteren af en klasse eller grænseflade at kontrollere den kode, der er ansvarlig for implementeringen af den, give en mere deklarativ måde end adgangsmodifikatorer til at begrænse brugen af en superklasse og understøtte fremtidige retninger i mønstermatchning ved at give et fundament til analyse af mønstre.
- Stærk indkapsling af JDK-interner som standard undtagen kritiske interne API'er som f.eks
misc. usikker. Brugere kan vælge den afslappede stærke indkapsling, der har været standard siden JDK 9. Målene i dette forslag inkluderer forbedring af sikkerhed og vedligeholdelse af JDK som en del af Project Jigsaw og tilskyndelse til udviklere til at migrere fra at bruge interne elementer til at bruge standard API'er, så at både udviklere og slutbrugere let kan opdatere til fremtidige Java-udgivelser. Dette forslag bærer en primær risiko for, at eksisterende Java-kode ikke kører. Udviklere opfordres til at bruge jdeps-værktøjet til at identificere kode, der afhænger af interne elementer i JDK og skifte til standardudskiftninger, når de er tilgængelige. Udviklere kan bruge en eksisterende udgivelse, såsom JDK 11, til at teste eksisterende kode ved hjælp af- ulovlig adgang = advarselat identificere interne elementer, der er adgang til via refleksion, ved hjælp af--illegal-access = debugfor at finde fejlkode og teste med- ulovlig adgang = nægte. - Udenlandsk linker API, der tilbyder statisk skrevet, ren Java-adgang til indfødt kode. Denne API vil være i et inkubator-trin i JDK 16. Sammen med den foreslåede API til fremmedhukommelsesadgang vil den udenlandske linker-API betydeligt forenkle den ellers fejlbehæftede proces med binding til et oprindeligt bibliotek. Denne plan er beregnet til at erstatte JNI (Java Native Interface) med en overlegen ren Java-udviklingsmodel, at tilbyde C-support og over tid være fleksibel nok til at rumme support til andre platforme, såsom 32-bit x86, og udenlandske funktioner skrevet på andre sprog end C, såsom C ++. Ydeevne skal være bedre end eller sammenlignelig med JNI.
- Flytning af ZGC (Z Garbage Collector) tråd-stack-behandling fra safepoints til en samtidig fase. Målene i denne plan inkluderer fjernelse af thread-stack-behandling fra ZGC-safepoint; gør stack-behandling doven, samarbejdsvillig, samtidig og inkrementel; fjernelse af al anden rodtrådbehandling pr. tråd fra ZGC-safepoint; og tilvejebringelse af en mekanisme for andre HotSpot VM-undersystemer til doven bearbejdning af stakke. ZGC er beregnet til at gøre GC-pauser og skalerbarhedsproblemer i HotSpot til fortiden. Indtil videre er GC-operationer, der skalerer med dyngens størrelse og størrelsen på metaspace, flyttet ud af safepoint-operationer og ind i samtidige faser. Disse har inkluderet markering, flytning, referencebehandling, klasseudlæsning og mest rodbehandling. De eneste aktiviteter, der stadig udføres i GC-safepoints, er en delmængde af rodbehandling og en tidsbegrænset markeringsafslutning. Disse rødder har inkluderet Java-trådstakke og andre trådrødder, hvor disse rødder er problematiske, fordi de skaleres med antallet af tråde. For at bevæge sig ud over den nuværende situation skal bearbejdning pr. Tråd, inklusive stakscanning, flyttes til en samtidig fase. Med denne plan skal gennemstrømningsomkostningerne ved den forbedrede latens være ubetydelig, og den tid, der bruges i ZGC-safepoint på typiske maskiner, skal være mindre end en millisekund.
- En elastisk metaspace-kapacitet, der returnerer ubrugt HotSpot VM-klasse metadatahukommelse (metaspace) hurtigere til OS, reducerer metaspace-fodaftryk og forenkler metaspace-kode for at reducere vedligeholdelsesomkostninger. Metaspace har haft problemer med høj hukommelse uden for bunke. Planen kræver udskiftning af den eksisterende hukommelsesalloker med en kompisbaseret tildelingsplan, der giver en algoritme til at opdele hukommelse i partitioner for at tilfredsstille hukommelsesanmodninger. Denne tilgang er blevet brugt på steder som Linux-kernen og vil gøre det praktisk at allokere hukommelse i mindre stykker for at reducere klasselæsseromkostningerne. Fragmentering vil også blive reduceret. Derudover vil forpligtelsen til hukommelse fra OS til hukommelsesadministrationsarenaer gøres doven, efter behov, for at reducere fodaftryk for læssere, der starter med store arenaer, men ikke bruger dem med det samme eller måske ikke bruger dem i deres fulde omfang. For fuldt ud at udnytte den elasticitet, der tilbydes ved kendeallokering, vil metaspace-hukommelse blive arrangeret i ensartede granulater, der kan begås og ikke-forpligtes uafhængigt af hinanden.
- Aktivering af C ++ 14 sprogfunktioner for at tillade brug af C ++ 14-funktioner i JDK C ++ kildekode og give specifik vejledning om, hvilke af disse funktioner der kan bruges i HotSpot VM-kode. Gennem JDK 15 er sprogfunktioner, der bruges af C ++ - kode i JDK, blevet begrænset til sprogstandarderne C ++ 98/03. Med JDK 11 blev kildekoden opdateret til understøttelse af bygning med nyere versioner af C ++ - standarden. Dette inkluderer at være i stand til at bygge med nyere versioner af compilers, der understøtter C ++ 11/14 sprogfunktioner. Dette forslag foreslår ikke ændringer i stil eller brug af C ++ - kode, der bruges uden for HotSpot. Men for at drage fordel af C ++ sprogfunktioner kræves nogle ændringer i byggetiden afhængigt af platformskompilatoren.
- En vektor-API i et inkubatortrin, hvor JDK vil blive udstyret med et inkubatormodul,
jdk.inkubator.vector, til at udtrykke vektorberegninger, der kompileres til optimale vektorhardwareanvisninger om understøttede CPU-arkitekturer, for at opnå overlegen ydelse til ækvivalente skalære beregninger. Vector API giver en mekanisme til at skrive komplekse vektoralgoritmer i Java ved hjælp af allerede eksisterende support i HotSpot VM til vektorisering, men med en brugermodel, der gør vektorisering mere forudsigelig og robust. Forslagets mål inkluderer levering af en klar og koncis API til at udtrykke en række vektorberegninger, idet de er platformagnostiske ved at understøtte flere CPU-arkitekturer og tilbyder pålidelig runtime-kompilering og ydeevne på x64- og AArch64-arkitekturer. Behagelig nedbrydning er også et mål, hvor en vektorberegning ville nedbrydes yndefuldt og stadig fungerer, hvis den ikke kan udtrykkes fuldt ud ved kørsel som en sekvens af hardwarevektorinstruktioner, enten fordi en arkitektur ikke understøtter nogle instruktioner, eller en anden CPU-arkitektur understøttes ikke . - Portering af JDK til Windows / AArch64-platformen. Med frigivelsen af ny serverklasse og forbruger AArch64 (ARM64) hardware er Windows / AArch64 blevet en vigtig platform på grund af efterspørgsel. Mens selve porteringen allerede er for det meste komplet, involverer fokus i dette forslag integration af porten i hovedlinjen JDK repository.
- Portering af JDK til Alpine Linux og til andre Linux-distributioner, der bruger musl som deres primære C-bibliotek, på x64- og AArch64-arkitekturer. Musl er en Linux-implementering af standardbiblioteksfunktionaliteten beskrevet i ISO C- og Posix-standarderne. Alpine Linux er almindeligt anvendt i skyinstallationer, mikrotjenester og containermiljøer på grund af dets lille billedstørrelse. Et Docker-billede til Linux er mindre end 6 MB. At lade Java løbe tør for kasser i sådanne indstillinger giver Tomcat, Jetty, Spring og andre populære rammer mulighed for at arbejde i disse miljøer. Ved at bruge jlink til at reducere størrelsen på Java-runtime kan en bruger oprette et endnu mindre billede, der er skræddersyet til at køre en bestemt applikation.
- Tilvejebringelse af arkivklasser, der fungerer som gennemsigtige bærere af uforanderlige data. Optegnelser kan betragtes som nominelle tupler. Records blev vist i JDK 14 og JDK 15. Denne indsats er som svar på klager over, at Java har været for detaljeret eller har for meget ceremoni. Planens mål inkluderer udformning af en objektorienteret konstruktion, der udtrykker en simpel sammenlægning af værdier, der hjælper udviklere med at fokusere på modellering af uforanderlige data i stedet for udvidelig adfærd, automatisk implementering af datadrevne metoder som f.eks.
lige medog accessors og bevarelse af langvarige Java-principper såsom nominel typing. - Tilføjelsen af Unix-domæne-sokkelkanaler, hvor Unix-domæne (AF_UNIX) -støtte understøttes til sokkelkanalen og server-sokkelkanal-API'erne i pakken nio.channels. Planen udvider også den nedarvede kanalmekanisme til at understøtte Unix-domæne-sokkelkanaler og server-sokkelkanaler. Unix-domænesockets bruges til kommunikation mellem processer på den samme vært. De ligner i de fleste henseender TCP / IP-stikkene bortset fra at de adresseres af filsystemets stienavne snarere end IP-adresser og portnumre. Målet med den nye funktion er at understøtte alle funktioner i Unix-domæne-sokkelkanaler, der er almindelige på tværs af større Unix-platforme og Windows. Unix-domæne-sokkelkanaler opfører sig det samme som eksisterende TCP / IP-kanaler med hensyn til læse- / skriveadfærd, forbindelsesopsætning, accept af indgående forbindelser fra servere og multiplexing med andre ikke-blokerende valgbare kanaler i en vælger. Unix-domænesockets er mere sikre og mere effektive end TCP / IP-loopback-forbindelser til lokal kommunikation mellem processer.
- Et API til fremmedhukommelsesadgang, der giver Java-programmer sikkert adgang til fremmed hukommelse uden for Java-bunken. Tidligere inkuberet i både JDK 14 og JDK 15 ville fremmedhukommelsesadgangs-API'en igen inkuberes i JDK 16 og tilføjede forbedringer. Der er foretaget ændringer, herunder en klarere rollefordeling mellem
MemorySegmentogMemoryAdressesgrænseflader. Målene med dette forslag inkluderer levering af en enkelt API til at fungere på forskellige former for fremmed hukommelse, herunder indfødt, vedvarende og administreret bunkehukommelse. API'et bør ikke underminere JVM's sikkerhed. At motivere forslaget er, at mange Java-programmer får adgang til fremmed hukommelse, såsom Ignite, Memcached og MapDB. Men Java API giver ikke en tilfredsstillende løsning for at få adgang til fremmed hukommelse. - Mønstertilpasning til
forekomst afoperatør, som også blev forhåndsvist i både JDK 14 og JDK 15. Det ville blive afsluttet i JDK 16. Mønstertilpasning tillader fælles logik i et program, nemlig den betingede udvinding af komponenter fra objekter, til at blive udtrykt mere kortfattet og sikkert. - Tilvejebringelse af jpackage-værktøjet til pakning af selvstændige Java-applikationer. Introduceret som et inkuberingsværktøj i JDK 14 forblev jpackage i inkubation i JDK 15. Med JDK 16 flytter jpackage sig til produktion, der understøtter indfødte pakkeformater for at give brugerne en naturlig installationsoplevelse og tillade starttidsparametre at blive specificeret på emballagetid. Formater inkluderer msi og exe på Windows, pkg og dmg på MacOS, og deb og rpm på Linux. Værktøjet kan påberåbes direkte fra kommandolinjen eller programmatisk. Det nye emballeringsværktøj adresserer en situation, hvor mange Java-applikationer skal installeres på indfødte platforme på en førsteklasses måde snarere end at blive placeret på klassestien eller modulstien. En installerbar pakke, der passer til den oprindelige platform, er nødvendig.
- Migrering af OpenJDK-kildekodelagre fra Mercurial til Git. At drive denne indsats er fordele ved metadatastørrelse i versionskontrolsystem og tilgængelige værktøjer og hosting.
- Migration til GitHub, relateret til Mercurial-to-Git-migrationen, med JDK 16-kildekodebaserer, der skal findes på det populære kodedelingswebsted. JDK-funktionsudgivelser og JDK-opdateringsudgivelser til Java 11 og senere vil være en del af denne plan. Overgangen til Git, GitHub og Skara for Mercurial JDK og JDK-sandkassen blev udført den 5. september og er åben for bidrag.
Tidlig adgang builds af JDK 16 til Linux, Windows og MacOS kan findes på jdk.java.net. Ligesom JDK 15 vil JDK 16 være en kortvarig frigivelse, der understøttes i seks måneder. JDK 17, der forventes i september 2021, vil være en langsigtet support (LTS) frigivelse, der vil modtage flere års støtte. Den aktuelle LTS-udgivelse, JDK 11, blev udgivet i september 2018.
