JDK 16: Naujos „Java 16“ funkcijos

„Java Development Kit“ (JDK) 16 pasiekė pradinį etapą, o tai reiškia, kad funkcijų rinkinys nuo 2020 m. Gruodžio 10 d. Yra užšaldytas. Naujos „JDK 16“ funkcijos yra nuo antros sandarių klasių peržiūros iki modelių derinimo su tuo pačiu metu kamino apdorojimas šiukšlių surinkimui.

JDK 16 bus standartinės „Java“ versijos, įdiegtos pagal JDK 15, kuri buvo pristatyta rugsėjo 15 d., Standartinis diegimas. Siūlomame išleidimo tvarkaraštyje JDK 16 pasieks antrąjį perėjimo etapą 2021 m. Sausio 14 d., Po to išleidimo kandidatai atvyks vasario 4 d. 2021 m. Vasario 18 d. Produkcijos leidimas turėtų būti paskelbtas 2021 m. Kovo 16 d.

Septyniolika pasiūlymų oficialiai nukreipti į JDK 16 nuo 2020 m. Gruodžio 10 d. Naujos „Java 16“ galimybės apima:

• Pasiūlyme dėl vertės pagrįstų klasių pateikiami įspėjimai primityvias įvyniojimo klases klasifikuoja kaip vertybines ir atmeta jų konstruktorius, kad juos būtų galima pašalinti, skatinant naujus įspėjimus apie nuvertėjimą. Pateikiami įspėjimai apie netinkamus bandymus sinchronizuoti vertėmis pagrįstų klasių egzemplioriuose „Java“ platformoje. Šias pastangas skatina „Valhalla“ projektas, kuris siekia žymiai patobulinti „Java“ programavimo modelį primityvių klasių pavidalu. Pirmykštės klasės skelbia, kad egzemplioriai nėra tapatūs ir gali įterpti įterptinius ar suplotus vaizdus, ​​kur egzempliorius galima laisvai nukopijuoti tarp atminties vietų ir užkoduoti naudojant egzempliorių laukų reikšmes. „Java“ primityvių klasių kūrimas ir įgyvendinimas dabar yra pakankamai subrendęs, kad būsimame leidime būtų galima numatyti tam tikrų „Java“ platformos klasių perėjimą prie primityvių klasių. Kandidatai į perėjimą neoficialiai API specifikacijose nurodomi kaip vertės pagrįstos klasės.
• Anksčiau JDK 15 peržiūrėtos antspauduotos klasės ir sąsajos riboja, kurios kitos klasės ir sąsajos gali jas išplėsti ar įgyvendinti. Plano tikslai yra leisti klasės ar sąsajos autoriui valdyti kodą, atsakingą už jo įgyvendinimą, pateikti deklaratyvesnį būdą nei prieigos modifikatoriai, siekiant apriboti superklasės naudojimą, ir remti būsimas modelių derinimo kryptis, suteikiant pagrindą modelių analizė.
• Pagal numatytuosius nustatymus stiprus JDK vidinių elementų sujungimas, išskyrus kritines vidines API, tokias kaip nesaugus. Vartotojai gali pasirinkti atsipalaidavusią stiprią kapsulę, kuri buvo numatytoji nuo JDK 9. Šio pasiūlymo tikslai yra pagerinti JDK, kaip projekto „Jigsaw“, saugumą ir palaikomumą, ir skatinti kūrėjus pereiti nuo vidaus elementų naudojimo prie standartinių API, kad kad tiek kūrėjai, tiek galutiniai vartotojai gali lengvai atnaujinti būsimus „Java“ leidimus. Šis pasiūlymas kelia pagrindinę riziką, kad esamo „Java“ kodo nepavyks paleisti. Kūrėjai raginami naudoti įrankį „jdeps“, kad nustatytų kodą, kuris priklauso nuo vidinių JDK elementų, ir, jei įmanoma, pereiti prie standartinių pakeitimų. Kūrėjai gali naudoti esamą leidimą, pvz., JDK 11, norėdami išbandyti esamą kodą naudodami- neteisėta prieiga = įspėti nustatyti vidinius elementus, prieinamus per refleksiją, naudojant--illegal-access = derinti tiksliai nustatyti klaidingą kodą ir bandymą naudojant - neteisėta prieiga = paneigti.
• Užsienio susiejimo API, siūlanti statinio tipo „Java“ prieigą prie savojo kodo. Ši API bus JDK 16 inkubatoriaus etape. Kartu su siūloma užsienio atminties prieigos API, užsienio susiejimo API žymiai supaprastins į klaidas linkusį susiejimo su gimtąja biblioteka procesą. Šis planas skirtas pakeisti JNI („Java Native Interface“) aukščiausio lygio „pure-Java“ kūrimo modeliu, pasiūlyti C palaikymą ir laikui bėgant būti pakankamai lankstus, kad būtų galima palaikyti kitas platformas, pvz., 32 bitų x86, ir užsienio funkcijos, parašytos ne C, o C, pavyzdžiui, C ++. Veiklos rezultatai turėtų būti geresni arba panašūs į JNI.
• „ZGC“ („Z Garbage Collector“) siūlų kaupimas iš saugojimo taškų perkeliamas į lygiagrečią fazę. Šio plano tikslai apima gijų apdorojimo pašalinimą iš ZGC seifų; kad kamino apdorojimas būtų tingus, bendradarbiaujantis, kartu veikiantis ir prieauginis; pašalinti visus kitus šaknų šakninius procesus iš ZGC saugojimo taškų; ir suteikti mechanizmą kitiems „HotSpot“ VM posistemiams tingiai apdoroti kaminus. „ZGC“ yra skirtas „GS“ pauzėms ir mastelio problemoms „HotSpot“ paversti praeitimi. Iki šiol GC operacijos, kurios keičiasi su kaupo dydžiu ir metatelpos dydžiu, buvo perkeltos iš saugaus taško operacijų ir į lygiagrečias fazes. Tai apėmė žymėjimą, perkėlimą, nuorodų apdorojimą, klasės iškrovimą ir daugumą šakninių procesų. Vienintelė veikla, dar atliekama GC saugos taškuose, yra šakninio apdorojimo pogrupis ir su laiku susieta žymėjimo nutraukimo operacija. Šios šaknys apėmė „Java“ gijų šakas ir kitas gijų šaknis, o šios šaknys yra problemiškos, nes jos keičiamos atsižvelgiant į gijų skaičių. Norėdami pereiti už dabartinės situacijos ribų, vienos gijos apdorojimas, įskaitant rietuvių nuskaitymą, turi būti perkeltas į vienu metu vykstantį etapą. Pagal šį planą pagerėjusio delsos pralaidumo sąnaudos turėtų būti nereikšmingos, o laikas, praleistas ZGC saugyklose tipinėse mašinose, turėtų būti trumpesnis nei viena milisekundė.
• Elastinga meta erdvės galimybė, kuri operatyviai grąžina nenaudojamą „HotSpot“ VM klasės metaduomenų (metatelpos) atmintį operacinei sistemai, sumažina meta erdvės pėdsakus ir supaprastina meto erdvės kodą, kad sumažėtų priežiūros išlaidos. „Metaspace“ iškilo problemų dėl didelio atminties naudojimo. Plane reikalaujama pakeisti esamą atminties paskirstiklį bičiuliu paremta paskirstymo schema, pateikiant algoritmą, kuris padalintų atmintį į skaidinius, kad būtų patenkintos atminties užklausos. Šis metodas buvo naudojamas tokiose vietose kaip „Linux“ branduolys, todėl bus praktiška paskirstyti atmintį mažesniais gabalais, kad sumažėtų klasės krautuvo pridėtinės išlaidos. Suskaidymas taip pat bus sumažintas. Be to, OS atminties įsipareigojimas atminties valdymo arenoms bus vykdomas tingiai, pagal pareikalavimą, siekiant sumažinti krautuvų, kurie pradeda savo veiklą didelėse arenose, tačiau nenaudoja jų iš karto arba gali nevisiškai panaudoti, pėdsaką. Norint visapusiškai išnaudoti bičiulių paskirstymo teikiamą elastingumą, metatelpos atmintis bus išdėstyta į vienodo dydžio granules, kurias galima skirti ir neįpareigoti nepriklausomai viena nuo kitos.
• „C ++ 14“ kalbos funkcijų įgalinimas, kad būtų galima naudoti „C ++ 14“ galimybes „JDK C ++“ šaltinio kode ir pateikiamos konkrečios rekomendacijos, kurios iš šių funkcijų gali būti naudojamos „HotSpot“ VM kode. Per JDK 15 kalbos funkcijos, kurias JDK naudoja C ++ kodas, apsiribojo C ++ 98/03 kalbos standartais. Naudojant JDK 11, šaltinio kodas buvo atnaujintas, kad būtų lengviau kurti naujesnes C ++ standarto versijas. Tai apima galimybę kurti naudojant naujausias kompiliatorių versijas, palaikančias C ++ 11/14 kalbos funkcijas. Šiame pasiūlyme nesiūlomi jokie C ++ kodo, naudojamo ne „HotSpot“, stiliaus ar naudojimo pakeitimai. Tačiau norint pasinaudoti C ++ kalbos funkcijomis, reikalingi tam tikri kūrimo laiko pakeitimai, atsižvelgiant į platformos kompiliatorių.
• Vektorinė API inkubatoriaus etape, kurioje JDK būtų įrengtas inkubatoriaus modulis, jdk.inkubatorius.vektorius, norint išreikšti vektorinius skaičiavimus, kurie sudaromi pagal optimalias vektorių aparatinės įrangos instrukcijas palaikomose procesoriaus architektūrose, kad būtų pasiektas didesnis našumas lygiaverčiams skaliariniams skaičiavimams. Vektorių API suteikia mechanizmą, leidžiantį rašyti sudėtingus vektorinius algoritmus „Java“ sistemoje, naudojant vektorizacijai iš anksto esamą palaikymą „HotSpot“ VM, tačiau naudojant vartotojo modelį, kuris leidžia vektorizaciją padaryti labiau nuspėjamą ir patikimą. Pasiūlymo tikslai yra pateikti aiškią ir glaustą API, leidžiančią išreikšti daugybę vektorinių skaičiavimų, būti platformos agnostika palaikant kelias procesoriaus architektūras ir patikimą vykdymo laiko kompiliavimą bei našumą x64 ir AArch64 architektūrose. Gracingas degradavimas taip pat yra tikslas, kuriame vektoriaus skaičiavimas grakščiai degraduotų ir vis tiek veiktų, jei jo negalima visiškai išreikšti vykdymo metu kaip aparatinės įrangos vektorinių instrukcijų seką, nes architektūra nepalaiko kai kurių instrukcijų arba nepalaikoma kita procesoriaus architektūra .
• JDK perkėlimas į „Windows / AArch64“ platformą. Išleidus naują serverio klasės ir vartotojų „AArch64“ (ARM64) aparatinę įrangą, „Windows“ / „AArch64“ tapo svarbia platforma dėl paklausos. Nors pats perkėlimas jau yra baigtas, šiame pasiūlyme daugiausia dėmesio skiriama uosto integravimui į pagrindinės JDK saugyklą.
• JDK perkėlimas į „Alpine Linux“ ir kitus „Linux“ paskirstymus, kuriuose „Musl“ yra pagrindinė C biblioteka, naudojant „x64“ ir „AArch64“ architektūras. „Musl“ yra „Linux“ standartinių bibliotekos funkcijų, aprašytų ISO C ir Posix standartuose, įgyvendinimas. Dėl mažo vaizdo dydžio „Alpine Linux“ yra plačiai pritaikytas debesų diegimo, mikropaslaugų ir konteinerių aplinkose. „Docker“ vaizdas, skirtas „Linux“, yra mažesnis nei 6 MB. Jei leisite „Java“ nebeveikti tokiuose nustatymuose, „Tomcat“, „Jetty“, „Spring“ ir kitos populiarios sistemos leis natūraliai dirbti šiose aplinkose. Naudodamas „jlink“, kad sumažintų „Java“ vykdymo laiko dydį, vartotojas gali sukurti dar mažesnį vaizdą, pritaikytą vykdyti konkrečią programą.
• Pateikti įrašų klases, kurios veikia kaip skaidrūs nekintamų duomenų laikikliai. Įrašus galima laikyti nominaliaisiais rinkiniais. Įrašai buvo peržiūrėti JDK 14 ir JDK 15. Šios pastangos yra atsakas į skundus, kad „Java“ buvo per daug verdi ar per daug ceremonijų. Plano tikslai yra sukurti į objektą orientuotą konstrukciją, išreiškiančią paprastą vertybių suvestinę, padedant kūrėjams sutelkti dėmesį į nekintamų duomenų modeliavimą, o ne į išplėstinį elgesį, automatiškai įdiegiant duomenimis pagrįstus metodus, tokius kaip lygu išlaikant senus „Java“ principus, tokius kaip vardinis spausdinimas.
• „Unix“ domeno lizdo kanalų pridėjimas, kuriame „Unix“ domeno (AF_UNIX) lizdo palaikymas pridedamas prie paketo „nio.channels“ lizdo kanalo ir serverio lizdo kanalo API. Planas taip pat išplečia paveldėtą kanalų mechanizmą, kad palaikytų „Unix“ domeno ir serverio lizdo kanalus. „Unix“ domenų lizdai naudojami tarpprocesiniam ryšiui tame pačiame pagrindiniame kompiuteryje. Jie daugeliu atžvilgių yra panašūs į TCP / IP lizdus, ​​išskyrus tai, kad juos adresuoja failų sistemos kelio pavadinimai, o ne IP adresai ir prievadų numeriai. Naujų galimybių tikslas yra palaikyti visas „Unix“ domeno lizdo kanalų funkcijas, kurios yra bendros visose pagrindinėse „Unix“ platformose ir „Windows“. „Unix“ domeno lizdo kanalai elgsis taip pat, kaip ir esami TCP / IP kanalai, kalbant apie skaitymo / rašymo elgseną, ryšio nustatymą, serverių priimamų ryšių priėmimą ir tankintuvą su kitais neužblokuojančiais pasirenkamais kanalais. „Unix“ domenų lizdai yra saugesni ir efektyvesni nei TCP / IP grįžtamojo ryšio jungtys vietiniam procesų ryšiui palaikyti.
• Užsienio atminties prieigos API, leidžianti „Java“ programoms saugiai pasiekti svetimą atmintį už „Java“ kaupo ribų. Anksčiau inkubuota tiek JDK 14, tiek JDK 15, užsienio atminties prieigos API bus pakartotinai inkubuojama JDK 16, pridedant patobulinimų. Buvo atlikti pakeitimai, įskaitant aiškesnį vaidmenų atskyrimą Atminties segmentas ir Atminties adresai sąsajos. Šio pasiūlymo tikslai yra suteikti vieną API, kad veiktų įvairių rūšių užsienio atmintis, įskaitant vietinę, nuolatinę ir valdomą kauptinę atmintį. API neturėtų pakenkti JVM saugumui. Pasiūlymą motyvuoja tai, kad daugelis „Java“ programų pasiekia užsienio atmintį, pvz., „Ignite“, „Memcached“ ir „MapDB“. Tačiau „Java“ API nepateikia patenkinamo sprendimo, kaip pasiekti užsienio atmintį.
• Rašto atitikimas egzempliorius operatorius, kuris taip pat buvo peržiūrėtas ir JDK 14, ir JDK 15. Jis bus baigtas JDK 16. Rašto suderinimas leidžia programoje bendrą logiką, būtent sąlyginį komponentų išskyrimą iš objektų, išreikšti glaudžiau ir saugiau.
• Pateikti „jpackage“ įrankį savarankiškoms „Java“ programoms pakuoti. „Jpackage“ pristatytas kaip inkubacinis įrankis JDK 14, o „Jpackage“ liko inkubacijoje JDK 15. Naudodamas „JDK 16“, „Jpackage“ pereina prie gamybos, palaikydamas natūralius paketų formatus, kad vartotojai gautų natūralią diegimo patirtį ir leistų pakuotės metu nurodyti paleidimo laiko parametrus. Formatai apima „msi“ ir „exe“ sistemoje „Windows“, „pkg“ ir „dmg“ „MacOS“ sistemose, „deb“ ir „rpm“ - „Linux“. Įrankį galima iškviesti tiesiogiai iš komandinės eilutės arba programiškai. Naujas pakavimo įrankis sprendžia situaciją, kai daugelį „Java“ programų reikia įdiegti vietinėse platformose pirmos klasės būdu, o ne įdėti į klasės ar modulio kelią. Reikalingas diegiamas paketas, tinkantis savajai platformai.
• „OpenJDK“ šaltinio kodų saugyklų perkėlimas iš „Mercurial“ į „Git“. Šios pastangos yra versijų valdymo sistemos metaduomenų dydžio, turimų įrankių ir prieglobos privalumai.
• Perkėlimas į „GitHub“, susijęs su „Mercurial-to-Git“ perkėlimu, o JDK 16 šaltinio kodų saugyklos turi būti populiarioje kodų bendrinimo svetainėje. „JDK“ leidimai ir „JDK“ atnaujinimų leidimai, skirti „Java 11“ ir naujesnėms versijoms, būtų šio plano dalis. „Mercurial JDK“ ir „JDK-sandbox“ perėjimas prie „Git“, „GitHub“ ir „Skara“ buvo atliktas rugsėjo 5 d.

Ankstyvosios prieigos JDK 16 versijas, skirtas „Linux“, „Windows“ ir „MacOS“, rasite svetainėje jdk.java.net. Kaip ir „JDK 15“, taip ir „JDK 16“ bus trumpalaikis leidimas, palaikomas šešis mėnesius. JDK 17, kurio terminas bus 2021 m. Rugsėjo mėn., Bus ilgalaikio palaikymo (LTS) leidimas, kuriam bus skirta kelerių metų parama. Dabartinis LTS leidimas „JDK 11“ buvo išleistas 2018 m. Rugsėjo mėn.