JDK 16: Nove funkcije v Javi 16

Java Development Kit (JDK) 16 je dosegel svojo začetno fazo pada, kar pomeni, da je nabor funkcij od 10. decembra 2020 zamrznjen. Nove funkcije v JDK 16 segajo od drugega predogleda zapečatenih razredov do ujemanja vzorcev s sočasno nitjo - predelava skladov za odvoz smeti.

JDK 16 bo referenčna izvedba različice standardne Jave, ki naj bi sledila JDK 15, ki je prispela 15. septembra. Predlagani urnik izdaje predvideva, da bo JDK 16 14. januarja 2021 v drugo stopnjo zatiranja, nato bodo kandidati za izdajo prispeli 4. februarja in 18. februarja 2021. Produkcija produkcije naj bi izšla 16. marca 2021.

Sedemnajst predlogov je uradno usmerjenih na JDK 16 od 10. decembra 2020. Nove zmogljivosti, ki prihajajo na Javo 16, vključujejo:

• Opozorila za predlog razredov, ki temeljijo na vrednosti, označujejo primitivne razrede ovitkov kot temelječe na vrednosti in opuščajo njihove konstruktorje za odstranitev, kar sproži nova opozorila o opuščanju. Zagotovljena so opozorila o neprimernih poskusih sinhronizacije na primerkih katerega koli razreda, ki temelji na vrednosti na platformi Java. Vodilo teh prizadevanj je projekt Valhalla, ki si prizadeva za znatno izboljšanje programskega modela Java v obliki primitivnih razredov. Primitivni razredi razglašajo primerke za brez identitete in z zmožnostjo vstavljenih ali sploščenih predstavitev, pri čemer je primere mogoče prosto kopirati med pomnilniškimi lokacijami in kodirati z vrednostmi polj primerkov. Zasnova in izvedba primitivnih razredov v Javi je zdaj dovolj zrela, da lahko v prihodnji izdaji predvidevamo selitev nekaterih razredov platforme Java v primitivne razrede. Kandidati za selitev so v specifikacijah API neuradno označeni kot razredi, ki temeljijo na vrednosti.
• Predhodno predogledani v JDK 15 zapečateni razredi in vmesniki omejujejo, kateri drugi razredi in vmesniki jih lahko razširijo ali izvedejo. Cilji načrta vključujejo omogočanje avtorju razreda ali vmesnika, da nadzoruje kodo, ki je odgovorna za njegovo izvajanje, zagotavlja bolj deklarativni način kot modifikatorji dostopa, da omejijo uporabo superklase, in podpira prihodnja navodila pri ujemanju vzorcev z zagotavljanjem temeljev za analiza vzorcev.
• Močna enkapsulacija notranjih elementov JDK privzeto, razen kritičnih notranjih API-jev, kot je razno Nevarno. Uporabniki lahko izberejo sproščeno močno inkapsulacijo, ki je privzeta od JDK 9. Cilji tega predloga vključujejo izboljšanje varnosti in vzdrževanja JDK kot dela Project Jigsaw ter spodbujanje razvijalcev, da preidejo z uporabe notranjih elementov na uporabo standardnih API-jev, tako da da lahko razvijalci in končni uporabniki enostavno posodobijo prihodnje izdaje Java. Ta predlog nosi glavno tveganje, da se obstoječa koda Java ne bo zagnala. Razvijalce spodbujamo, da z orodjem jdeps prepoznajo kodo, ki je odvisna od notranjih elementov JDK, in preklopijo na standardne nadomestke, če so na voljo. Razvijalci lahko za preizkus obstoječe kode z uporabo obstoječe izdaje, na primer JDK 11, uporabijo--illegal-access = opozorilo za prepoznavanje notranjih elementov, do katerih lahko pridete z refleksijo, z uporabo--illegal-access = odpravljanje napak za določitev napačne kode in testiranje z --illegal-access = zavrni.
• API za tuje povezovalnike, ki ponuja statično natipkan dostop s čisto Javo do izvorne kode. Ta API bo v fazi inkubatorja v JDK 16. Skupaj s predlaganim API-jem za dostop do tujega pomnilnika bo API tujega povezovalnika znatno poenostavil postopek, ki je navaden na napake in je vezan na izvorno knjižnico. Ta načrt naj bi nadomestil JNI (Java Native Interface) z vrhunskim razvojnim modelom iz čiste Java, ponudil podporo C in sčasoma dovolj prilagodljiv za podporo drugim platformam, kot je 32-bitni x86, in tuje funkcije, napisane v jezikih, ki niso C, kot je C ++. Učinkovitost bi morala biti boljša ali primerljiva z JNI.
• Premikanje obdelave zložkov niti ZGC (Z Garbage Collector) iz varnih točk v sočasno fazo. Cilji tega načrta vključujejo odstranjevanje obdelave skladov niti z varnostnih točk ZGC; zaradi česar je obdelava skladov lena, kooperativna, sočasna in postopna; odstranjevanje vseh ostalih korenskih obdelav na nit iz varnostnih točk ZGC; in zagotavljanje mehanizma za druge podsisteme HotSpot VM za lenobno obdelavo skladov. ZGC naj bi zaustavil GC in težave z razširljivostjo v HotSpotu v preteklosti. Doslej so bile operacije GC, ki se spreminjajo glede na velikost kupa in velikost metaprostora, premaknjene iz operacij varne točke v sočasne faze. Sem spadajo označevanje, selitev, referenčna obdelava, razkladanje razredov in večina korenske obdelave. Edine dejavnosti, ki se še vedno izvajajo v zaščitnih točkah GC, so podskupina korenske obdelave in časovno omejena operacija zaključevanja označevanja. Te korenine vključujejo sklope niti Java in druge korenine niti, pri čemer so te korenine problematične, ker se spreminjajo glede na število niti. Če želite preseči trenutno situacijo, je treba obdelavo na nit, vključno s pregledovanjem skladov, premakniti v sočasno fazo. S tem načrtom bi morali biti pretočni stroški izboljšane zakasnitve nepomembni, čas, porabljen znotraj varnostnih točk ZGC na tipičnih strojih, pa manj kot eno milisekundo.
• Elastična zmožnost metaprostora, ki v OS hitreje vrne neuporabljeni pomnilnik metapodatkov (metaprostor) razreda HotSpot VM, zmanjša odtis metaprostora in poenostavi kodo metaprostora, da zmanjša stroške vzdrževanja. Metaspace je imel težave z veliko porabo pomnilnika. Načrt zahteva zamenjavo obstoječega razdeljevalnika pomnilnika s shemo dodeljevanja, ki temelji na prijateljih, in zagotavlja algoritem za razdelitev pomnilnika na particije, da se zadovoljijo zahteve po pomnilniku. Ta pristop je bil uporabljen v krajih, kot je jedro Linuxa, zato bo praktično razporediti pomnilnik v manjših kosih, da se zmanjšajo obremenitve razreda za nalaganje. Zmanjšala se bo tudi razdrobljenost. Poleg tega bo zajem pomnilnika iz operacijskega sistema za arene za upravljanje pomnilnika lenobno opravljen na zahtevo, da se zmanjša odtis nakladalcev, ki začnejo z velikimi arenami, vendar jih ne uporabijo takoj ali jih morda ne bodo uporabljali v celoti. Da bi v celoti izkoristili elastičnost, ki jo ponuja dodelitev prijateljev, bo pomnilnik metaprostora razporejen v enakomerno velike zrnca, ki jih je mogoče ločiti in razvezati neodvisno drug od drugega.
• Omogočanje jezikovnih funkcij C ++ 14, da se omogoči uporaba zmožnosti C ++ 14 v izvorni kodi JDK C ++ in podajo natančna navodila o tem, katere od teh funkcij je mogoče uporabiti v kodi HotSpot VM. Skozi JDK 15 so bile jezikovne funkcije, ki jih uporablja koda C ++ v JDK, omejene na jezikovne standarde C ++ 98/03. Z JDK 11 je bila izvorna koda posodobljena tako, da podpira gradnjo z novejšimi različicami standarda C ++. To vključuje zmožnost gradnje z najnovejšimi različicami prevajalnikov, ki podpirajo jezikovne funkcije C ++ 11/14. Ta predlog ne predlaga sprememb sloga ali uporabe za kodo C ++, ki se uporablja zunaj HotSpot. Da pa bi izkoristili funkcije jezika C ++, so potrebne nekatere spremembe časa gradnje, odvisno od prevajalnika platforme.
• Vektorski API v fazi inkubatorja, v katerem bi bil JDK opremljen z inkubatorskim modulom, jdk.incubator.vectorza izražanje vektorskih izračunov, ki se zbirajo v optimalna vektorska navodila o strojni opremi na podprtih arhitekturah CPU, za doseganje boljše zmogljivosti kot enakovredni skalarni izračuni. Vektorski API ponuja mehanizem za pisanje kompleksnih vektorskih algoritmov v Javi z uporabo že obstoječe podpore v HotSpot VM za vektorizacijo, vendar z uporabniškim modelom, ki vektorizacijo naredi bolj predvidljivo in robustno. Cilji predloga vključujejo zagotavljanje jasnega in jedrnatega API-ja za izražanje vrste vektorskih izračunov, ki je agnostičen na platformo s podporo več arhitektur CPU ter ponuja zanesljivo kompilacijo in zmogljivost izvajalnega okolja na arhitekturah x64 in AArch64. Cilj je tudi graciozna degradacija, pri kateri bi se vektorski izračun elegantno poslabšal in še vedno deloval, če ga med izvajanjem ni mogoče popolnoma izraziti kot zaporedje vektorskih navodil strojne opreme, bodisi zato, ker arhitektura ne podpira nekaterih navodil bodisi druga arhitektura CPU ni podprta .
• Prenos JDK na platformo Windows / AArch64. Z izdajo nove strežniške in potrošniške strojne opreme AArch64 (ARM64) je Windows / AArch64 zaradi povpraševanja postal pomembna platforma. Čeprav je samo prenos že večinoma končan, je v ospredju tega predloga integracija vrat v glavno odlagališče JDK.
• Prenos JDK na Alpine Linux in druge distribucije Linuxa, ki uporabljajo musl kot svojo primarno knjižnico C, na arhitekturah x64 in AArch64. Musl je implementacija standardne knjižnične funkcionalnosti, opisane v standardih ISO C in Posix, za Linux. Alpine Linux je zaradi svoje majhnosti slike široko sprejet v oblakih, mikro storitvah in okoljih vsebnikov. Slika Dockerja za Linux je manjša od 6 MB. Če v takšnih nastavitvah pustite, da Java teče iz samega sebe, bo Tomcat, Jetty, Spring in drugi priljubljeni ogrodji delovali v teh okoljih. Z uporabo jlink za zmanjšanje velikosti izvajalnega okolja Java lahko uporabnik ustvari še manjšo sliko, prilagojeno za zagon določene aplikacije.
• Zagotavljanje razredov zapisov, ki delujejo kot pregledni nosilci nespremenljivih podatkov. Zapise lahko štejemo za nominalne korice. Zapisi so bili predogledani v JDK 14 in JDK 15. Ta prizadevanja so odgovor na pritožbe, da je bila Java preveč podrobna ali ima preveč slovesnosti. Cilji načrta vključujejo oblikovanje objektno usmerjenega konstrukta, ki izraža preprosto združevanje vrednosti, pomaga razvijalcem, da se osredotočijo na modeliranje nespremenljivih podatkov namesto na razširljivo vedenje, in samodejno izvajajo metode, ki temeljijo na podatkih, kot je npr. enako in dodatki ter ohranjanje dolgoletnih načel Java, kot je nominalno tipkanje.
• Dodatek vtičničnih kanalov domene Unix, pri katerih je podpora za vtičnico Unix domene (AF_UNIX) dodana API-jem vtičnic in kanalov vtičnice strežnika v paketu nio.channels Načrt tudi razširja podedovani mehanizem kanalov za podporo vtičničnih kanalov domene Unix in kanalov vtičnic strežnika. Vtičnice domene Unix se uporabljajo za medprocesno komunikacijo na istem gostitelju. V večini vidikov so podobni vtičnicam TCP / IP, le da jih naslavljajo imena poti datotečnega sistema in ne naslovi IP in številke vrat. Cilj nove zmogljivosti je podpirati vse funkcije vtičničnih kanalov domene Unix, ki so pogoste v večjih platformah Unix in Windows. Kanali vtičnic domene Unix se bodo obnašali enako kot obstoječi kanali TCP / IP glede vedenja branja / pisanja, nastavitve povezave, sprejemanja dohodnih povezav s strani strežnikov in multipleksiranja z drugimi neblokirajočimi izbirnimi kanali v izbirniku. Vtičnice domene Unix so varnejše in učinkovitejše od povratnih povezav TCP / IP za lokalne medprocesne komunikacije.
• API za dostop do tujega pomnilnika, ki programom Java omogoča varen dostop do tujega pomnilnika zunaj kopice Java. Prej inkubiran v JDK 14 in JDK 15, bi bil API za dostop do tujega pomnilnika ponovno inkubiran v JDK 16 in dodal izboljšave. Spremenjene so bile tudi jasnejša ločitev vlog med MemorySegment in Naslovi Memory vmesniki. Cilji tega predloga vključujejo zagotavljanje enotnega API-ja za delovanje na različnih vrstah tujega pomnilnika, vključno z naravnim, trajnim in upravljanim kupom pomnilnika. API ne sme ogroziti varnosti JVM. Motivira predlog, da mnogi programi Java dostopajo do tujega pomnilnika, kot so Ignite, Memcached in MapDB. Toda Java API ne nudi zadovoljive rešitve za dostop do tujega pomnilnika.
• Ujemanje vzorcev za instanceof operator, ki je bil predogledan tudi v JDK 14 in JDK 15. Dokončan bi bil v JDK 16. Ujemanje vzorcev omogoča, da je skupna logika v programu, in sicer pogojno ekstrahiranje komponent iz predmetov, bolj jedrnato in varno.
• Zagotavljanje orodja jpackage za pakiranje samostojnih aplikacij Java. Jpackage, uveden kot orodje za inkubiranje v JDK 14, je ostal v inkubaciji v JDK 15. Z JDK 16 se jpackage premakne v proizvodnjo in podpira izvorne formate paketov, da uporabnikom omogoči naravno namestitev in omogoči določitev parametrov časa zagona v času pakiranja. Formati vključujejo msi in exe v operacijskem sistemu Windows, pkg in dmg na MacOS ter deb in rpm na Linuxu. Orodje lahko prikličete neposredno iz ukazne vrstice ali programsko. Novo orodje za pakiranje obravnava situacijo, v kateri je treba številne programe Java namestiti na izvorne platforme prvovrstno, namesto da bi jih postavili na pot razreda ali modul. Potreben je namestitveni paket, primeren za izvorno platformo.
• Migracija skladišč izvorne kode OpenJDK iz Mercuriala v Git. Spodbujanje tega napora so prednosti velikosti metapodatkov sistema za nadzor različic ter razpoložljivih orodij in gostovanja.
• Migracija na GitHub, povezana z migracijo Mercurial-to-Git, s skladišči izvorne kode JDK 16, ki bodo na priljubljenem spletnem mestu za skupno rabo kode. Izdaje funkcij JDK in posodobitve JDK za Javo 11 in novejše bodo del tega načrta. Prehod na Git, GitHub in Skara za Mercurial JDK in JDK-sandbox je bil izveden 5. septembra in je na voljo za prispevke.

Zgradbe JDK 16 za zgodnji dostop za Linux, Windows in MacOS najdete na jdk.java.net. Tako kot JDK 15 bo tudi JDK 16 kratkoročna izdaja, podprta šest mesecev. JDK 17, ki bo izšel septembra 2021, bo izdan za dolgoročno podporo (LTS), ki bo deležen večletne podpore. Trenutna izdaja LTS, JDK 11, je izšla septembra 2018.