JDK 15: Naujos „Java 15“ funkcijos

„Java Development Kit 15“, „Oracle“ naujos versijos „Java SE“ („Standard Edition“) diegimas, bus pasiekiamas kaip gamybos leidimas šiandien, 2020 m. Rugsėjo 15 d. „JDK 15“ svarbiausi dalykai yra teksto blokai, paslėptos klasės, prieigos prie užsienio atminties API, „Z“ šiukšlių surinkėjas ir užklijuotų klasių peržiūros, modelių derinimas ir įrašai.

„JDK 15“ yra tik trumpalaikis leidimas, kurį „Oracle Premier“ palaikoma tik šešis mėnesius, kol ateis kitų metų kovo mėn. JDK 17, kitas ilgalaikio palaikymo leidimas, kurį „Oracle“ palaiko aštuonerius metus, turėtų pasirodyti po vienerių metų, kaip numatyta „Oracle“ šešių mėnesių „Java SE“ versijų leidimo kadencijoje.

Kūrėjai gali pažvelgti į JDK 15 dabar, norėdami sužinoti, kas bus JDK 17, sakė Georgesas Saabas, „Oracle“ „Java Platform Group“ prezidentas. Dabartinis LTS leidimas yra JDK 11, kuris pasirodė 2018 m. Rugsėjo mėn. LTS leidimai pateikiami kas trejus metus. JDK 15 seka JDK 14, kuris buvo išleistas 2020 m. Kovo 17 d.

Naujos „OpenJDK 15“ funkcijos ir pakeitimai:

• Antrasis užsienio atminties prieigos API inkubatorius, leidžiantis „Java“ programoms saugiai ir efektyviai pasiekti svetimą atmintį už „Java“ krūvos ribų. API turėtų sugebėti valdyti įvairias užsienio atmintis, tokias kaip vietinė, patvari ir valdoma kaupa. Daugelis „Java“ programų pasiekia užsienio atmintį, pvz., „Ignite“ ir „MapDB“. API padėtų išvengti sąnaudų ir nenuspėjamumo, susijusių su šiukšlių surinkimu, dalytis atmintimi procesų metu ir nuosekliai kaupti bei deserializuoti atminties turinį susiejant failus į atmintį. „Java“ API šiuo metu nepateikia patenkinamo sprendimo, kaip pasiekti užsienio atmintį. Tačiau pateikus naują pasiūlymą, API neturėtų būti įmanoma pakenkti JVM saugumui. Ši galimybė išgyvena ankstesnę inkubatoriaus fazę JDK 14, o patobulinimai siūlomi JDK 15.
• Užantspauduotų klasių peržiūra. Uždarosios klasės kartu su sąsajomis riboja, kurios kitos klasės ar sąsajos gali jas išplėsti ar įgyvendinti. Šios funkcijos tikslai yra leisti klasės ar sąsajos autoriui kontroliuoti, kuris kodas yra atsakingas už jo įgyvendinimą, suteikti deklaratyvesnį būdą nei prieigos modifikatoriai, kad būtų ribojamas superklasės naudojimas, ir remti būsimas modelių derinimo kryptis, grindžiant baigtinį modelių analizė.
• Šaltinio kodo pašalinimas ir „Solaris / SPARC“, „Solaris / x64“ ir „Linux / SPARC“ prievadų palaikymas, kurie buvo nebenaudojami pašalinti JDK 14 ketinant juos pašalinti būsimame leidime. Daugeliui kuriamų projektų ir funkcijų, tokių kaip „Valhalla“, „Loom“ ir „Panama“, reikia reikšmingų procesoriaus architektūros ir operacinės sistemos kodo pakeitimų. Nutraukus palaikymą „Solaris“ ir SPARC uostams, „OpenJDK“ bendruomenės dalyviai galės paspartinti naujų funkcijų, kurios perkelia platformą į priekį, kūrimą. Pastaraisiais metais tiek „Solaris“, tiek „SPARC“ pakeitė „Linux“ ir „Intel“ procesoriai.
• Įrašai, kurios yra klasės, veikiančios kaip nekintamų duomenų skaidrūs nešikliai, būtų įtraukiami į antrąją JDK 15 peržiūros versiją, po to, kai JDK 14 bus debiutuota kaip išankstinė peržiūra. paprastas reikšmių agregavimas, padedantis programuotojams sutelkti dėmesį į nekintamų duomenų modeliavimą, o ne į išplėstinį elgesį, automatiškai įdiegti duomenimis pagrįstus metodus, tokius kaip lygūs ir vertintojai, ir išsaugoti ilgalaikius „Java“ principus, tokius kaip nominalus rinkimas ir perkėlimo suderinamumas. Įrašus galima laikyti nominaliaisiais rinkiniais.
• Kriptografiniai parašai, pagrįsti „Edwards-Curve“ skaitmeninio parašo algoritmu (EdDSA). „EdDSA“ yra moderni elipsės kreivės schema, turinti pranašumų, palyginti su esamomis JDK parašo schemomis. „EdDSA“ bus įdiegta tik „SunEC“ teikėjui. „EdDSA“ yra paklausa dėl patobulinto saugumo ir našumo, palyginti su kitomis parašų schemomis; jis jau palaikomas kriptografinėse bibliotekose, tokiose kaip „OpenSSL“ ir „BoringSSL“.
• Atnaujinti seną „DatagramSocket“ API pakeičiant pagrindiniusjava.net.datagram.Socket ir java.net.MulticastSocket API su paprastesniais ir modernesniais diegimais, kuriuos 1. lengva derinti ir prižiūrėti ir 2. dirbti su virtualiomis gijomis, kurios šiuo metu tiriamos „Project Loom“. Naujasis planas yra tęsinys pagal JDK patobulinimo 353 pasiūlymą, kuris atnaujino seną „Socket“ API. Dabartinis programos įgyvendinimas java.net.datagram.Socket ir java.net.MulticastSocket datuojamas JDK 1.0 ir tuo metu, kai „IPv6“ dar buvo kuriamas. Taigi dabartinis programos įgyvendinimas„MulticastSocket“ bando suderinti IPv4 ir IPv6 sunkiai prižiūrimais būdais.
• Pagal numatytuosius nustatymus išjungiamas šališkas užrakinimas ir panaikinamos visos susijusios komandų eilutės parinktys. Tikslas yra nustatyti, ar reikia nuolat palaikyti brangiai prižiūrimą, šališką užraktą optimizuojantį seną sinchronizavimą, kuris naudojamas „HotSpot“ virtualioje mašinoje, kad būtų sumažintos pridėtinės užrakinimo išlaidos. Nors kai kurios „Java“ programos gali regresuoti našumą, kai išjungtas šališkas užraktas, šališko užrakinimo našumas paprastai nėra toks akivaizdus nei anksčiau.
• Antroji šablono atitikimo peržiūra egzemplioriusPagal ankstesnę JDK 14 peržiūrą. Šablonų suderinimas leidžia lengviau ir glaustai išreikšti bendrą programos logiką, daugiausia sąlyginį komponentų išskyrimą iš objektų. Tokios kalbos kaip „Haskell“ ir „C #“, pritaikė modelių derinimą dėl jo trumpumo ir saugumo.
• Paslėptos klasės, t. Y. Klasės, kurių tiesiogiai naudoti negali kitų klasių baitkodas, yra skirtos naudoti sistemoms, kurios generuoja klases vykdymo metu ir naudoja jas netiesiogiai atspindėdami. Paslėptą klasę galima apibrėžti kaip prieigos kontrolės lizdo narį ir ją galima iškrauti nepriklausomai nuo kitų klasių. Pasiūlymas padidintų visų JVM kalbų efektyvumą, nes standartinė API leistų apibrėžti paslėptas klases, kurių negalima rasti ir kurių gyvenimo ciklas yra ribotas. JDK viduje ir už jos ribų esančios sistemos galėtų dinamiškai generuoti klases, kurios vietoj to galėtų apibrėžti paslėptas klases. Daugelis kalbų, pagrįstų JVM, remiasi dinamišku klasių generavimu, kad būtų lankstus ir efektyvus. Šio pasiūlymo tikslai yra šie: leisti struktūroms apibrėžti klases kaip neatrastinas sistemos įgyvendinimo detales, todėl jų negalima susieti su kitomis klasėmis ir aptikti refleksija; parama, kaip išplėsti patekimo kontrolės lizdą su neaptinkamomis klasėmis; palaikymas agresyviam neatrastų klasių iškrovimui, todėl sistemos gali lanksčiai apibrėžti tiek, kiek reikia. Kitas tikslas yra nebenaudoti nestandartinės API,misc.Unsafe :: defineAnonymousClass, ketindami atsisakyti pašalinimo būsimame leidime. Be to, dėl šio pasiūlymo negalima keisti „Java“ kalbos.
• Pagal šį pasiūlymą „Z Garbage Collector“ (ZGC) baigia gaminio eksperimentinę funkciją. Integruotas į „JDK 11“, kuris atkeliavo 2018 m. Rugsėjo mėn., „ZGC“ yra keičiamas, mažo vėlavimo šiukšlių surinkėjas. ZGC buvo pristatytas kaip eksperimentinis pajėgumas, nes „Java“ kūrėjai nusprendė, kad tokio dydžio ir sudėtingumo ypatybė turėtų būti atidžiai ir palaipsniui. Nuo to laiko buvo pridėta daugybė patobulinimų, pradedant vienu metu vykstančiais klasės iškrovimais, nepanaudotos atminties prisiėmimu ir palaikymu dalijantis klasės duomenimis, iki patobulinto NUMA supratimo ir kelių sričių krūvos išankstinio palietimo. Be to, maksimalus krūvos dydis buvo padidintas nuo keturių terabaitų iki 16 terabaitų. ZGC sprendžia našumo problemas tokiose programose, kurios apima didžiulį duomenų kiekį, pvz., Mašininį mokymąsi, kur vartotojai nori būti tikri, kad duomenų tvarkymas nebus susijęs su nenuspėjamumu ar ilgomis pauzėmis dėl šiukšlių surinkimo. Palaikomos platformos apima „Linux“, „Windows“ ir „MacOS“.
• Teksto blokai, peržiūrėti ir JDK 14, ir JDK 13, skirti supaprastinti „Java“ programų rašymo užduotį, palengvinant eilių, kurios apima kelias pirminio kodo eilutes, išraišką, tuo pačiu išvengiant pabėgimo sekų dažniausiai. Teksto blokas yra kelių eilučių eilutės literalas, kuris nereikalauja daugumos pabėgimo sekų, automatiškai formatuoja eilutę nuspėjamu būdu ir siūlo kūrėjui valdyti formatą, kai to pageidaujama. Pasiūlymo dėl teksto blokų tikslas yra pagerinti „Java“ programų eilučių, žyminčių ne „Java“ kalbomis parašytą kodą, įskaitomumą. Kitas tikslas yra remti perėjimą nuo eilutės literalų, nurodant, kad bet kuris naujas konstruktas gali išreikšti tą patį eilučių rinkinį kaip eilutės literalas, interpretuoti tas pačias pabėgimo sekas ir būti manipuliuojamas taip pat, kaip ir eilutės literalas. „OpenJDK“ kūrėjai tikisi pridėti pabėgimo sekų, kad valdytų aiškų baltąjį plotą ir naujų linijų valdymą.
• „Shenandoah“ mažo pristabdymo laiko šiukšlių surinkėjas taptų gamybos funkcija ir išeitų iš eksperimento etapo. Prieš metus jis buvo integruotas į JDK 12.
• „Nashorn“ pašalinimas, kuris debiutavo JDK 8 2014 m. Kovo mėn., Tačiau nuo to laiko paseno tokiomis technologijomis kaip „GraalVM“. Pasiūlyme „OpenJDK 15“ reikalaujama pašalinti „Nashorn“ API ir „jjs“ komandų eilutės įrankį, naudojamą „Nashorn“ iškviesti.
• Panaikinamas RMI aktyvavimo mechanizmas, kad ateityje būtų galima jį pašalinti. RMI aktyvinimo mechanizmas yra pasenusi RMI dalis, kuri buvo neprivaloma nuo „Java 8“. RMI aktyvinimas kelia nuolatinę priežiūros naštą. Jokia kita RMI dalis nebus nebenaudojama.