JDK 16: Java 16 jaunās funkcijas

Java izstrādes komplekts (JDK) 16 ir sasniedzis sākotnējo samazināšanas fāzi, kas nozīmē, ka funkciju kopa tagad ir iesaldēta, sākot ar 2020. gada 10. decembri. JDK 16 jaunās funkcijas ir no otra aizzīmogotu klašu priekšskatījuma līdz rakstu saskaņošanai ar vienlaicīgām pavedieniem. kaudzes apstrāde atkritumu savākšanai.

JDK 16 būs standarta Java versijas atsauces ieviešana, kas sekos JDK 15, kas ieradās 15. septembrī. Ierosinātajā izlaišanas grafikā JDK 16 sasniegs otro samazināšanas fāzi 2021. gada 14. janvārī, kam sekos atbrīvošanas kandidāti, kas ieradīsies 4. un 2. februārī. 2021. gada 18. februārī paredzēts, ka produkcijas izlaidums tiks publicēts 2021. gada 16. martā.

Septiņpadsmit priekšlikumi oficiāli attiecas uz JDK 16 no 2020. gada 10. decembra. Java 16 jaunās iespējas ietver:

• Priekšlikumā par vērtību balstītu klašu brīdinājumi primitīvās iesaiņošanas klases tiek noteiktas kā vērtības balstītas un tiek novecoti to konstruktori noņemšanai, tādējādi radot jaunus brīdinājumus par nolietojumu. Tiek sniegti brīdinājumi par nepareiziem mēģinājumiem sinhronizēt jebkuras uz vērtību balstītas klases gadījumus Java platformā. Šīs pūles ir Valhalla projekts, kas primitīvu nodarbību veidā ievērojami uzlabo Java programmēšanas modeli. Primitīvās klases paziņo, ka gadījumi nav identitātes un spējīgi iekļaut vai saplacinātus attēlojumus, kur gadījumus var brīvi kopēt starp atmiņas vietām un kodēt, izmantojot instanču lauku vērtības. Primitīvo klašu dizains un ieviešana Java tagad ir pietiekami nobriedusi, lai nākotnē varētu paredzēt noteiktu Java platformas klašu migrāciju uz primitīvām klasēm. Kandidāti migrācijai API specifikācijās neoficiāli tiek norādīti kā uz vērtību balstītas klases.
• Iepriekš apskatīti JDK 15, aizzīmogotās klases un saskarnes ierobežo to, kuras citas klases un saskarnes tos var paplašināt vai ieviest. Plāna mērķi ietver iespēju atļaut klases vai saskarnes autoram kontrolēt kodu, kas atbild par tā ieviešanu, nodrošināt deklaratīvāku veidu nekā piekļuves modifikatori, lai ierobežotu superklases izmantošanu, un atbalstīt nākotnes virzienus modeļu saskaņošanā, nodrošinot pamatu modeļu analīze.
• Pēc noklusējuma spēcīga JDK iekšējo materiālu iekapsulēšana, izņemot kritiskas iekšējās API, piemēram, nederīgs. Lietotāji var izvēlēties atvieglinātu spēcīgu iekapsulēšanu, kas ir noklusējums kopš JDK 9. Šī priekšlikuma mērķi ietver JDK drošības un uzturēšanas uzlabošanu kā projekta finierzāģa daļu un mudina izstrādātājus pāriet no iekšējo elementu izmantošanas uz standarta API izmantošanu, lai ko gan izstrādātāji, gan galalietotāji var viegli atjaunināt uz nākamajiem Java izlaidumiem. Šim priekšlikumam ir primārs risks, ka esošo Java kodu neizdosies palaist. Izstrādātāji tiek aicināti izmantot rīku jdeps, lai identificētu kodu, kas atkarīgs no JDK iekšējiem elementiem, un pēc iespējas pāriet uz standarta aizstājējiem. Izstrādātāji var izmantot esošu laidienu, piemēram, JDK 11, lai pārbaudītu esošo kodu, izmantojot--illegal-access = brīdināt lai identificētu iekšējos elementus, kuriem piekļūst, izmantojot refleksiju, izmantojot--illegal-access = atkļūdošana precīzi noteikt kļūdainu kodu un testēšanu ar --illegal-access = noliegt.
• Ārzemju saišu API, kas piedāvā statiski ierakstītu tīru Java piekļuvi vietējam kodam. Šī API būs inkubatora stadijā JDK 16. Kopā ar piedāvāto svešās atmiņas piekļuves API ārzemju saistītāja API ievērojami vienkāršos citādi kļūdām raksturīgo saistīšanas procesu ar vietējo bibliotēku. Šis plāns ir paredzēts, lai aizstātu JNI (Java vietējo saskarni) ar izcilu tīras Java izstrādes modeli, lai piedāvātu C atbalstu un laika gaitā būtu pietiekami elastīgs, lai pielāgotos atbalstam citām platformām, piemēram, 32 bitu x86, un svešas funkcijas, kas rakstītas valodās, kas nav C, piemēram, C ++. Darbībai jābūt labākai vai salīdzināmai ar JNI.
• ZGC (Z Garbage Collector) pavedienu kaudzes apstrādes pārvietošana no drošpunktiem uz vienlaicīgu fāzi. Šī plāna mērķi ietver pavedienu kaudzes apstrādes noņemšanu no ZGC drošības punktiem; padarīt kaudzes apstrādi slinku, kooperatīvu, vienlaicīgu un inkrementālu; visu citu pavedienu sakņu apstrādes noņemšana no ZGC drošības punktiem; un nodrošinot mehānismu citām HotSpot VM apakšsistēmām, lai slinki apstrādātu kaudzes. ZGC mērķis ir padarīt GC pauzes un mērogojamības problēmas HotSpot pagātnē. Līdz šim GC darbības, kas mērogojas ar kaudzes lielumu un metatelpas lielumu, ir pārvietotas no drošpunktu operācijām un vienlaikus fāzēs. Tajos ietilpst marķēšana, pārvietošana, atsauču apstrāde, klases izkraušana un lielākā daļa sakņu apstrādes. Vienīgās darbības, kas joprojām tiek veiktas GC drošības punktos, ir sakņu apstrādes apakškopa un ar laiku saistīta marķēšanas izbeigšanas darbība. Šīs saknes ir iekļāvušas Java pavedienu kaudzes un citas pavedienu saknes, un šīs saknes ir problemātiskas, jo tās mērogojas ar pavedienu skaitu. Lai pārietu no pašreizējās situācijas, viena pavediena apstrāde, ieskaitot skenēšanu, jāpārvieto uz vienlaicīgu fāzi. Izmantojot šo plānu, uzlabotās latentuma caurlaides izmaksām jābūt nenozīmīgām, un laikam, kas pavadīts ZGC drošības punktos tipiskām mašīnām, jābūt mazākam par vienu milisekundi.
• Elastīga metatelpas spēja, kas operētājsistēmai ātrāk atdod neizmantoto HotSpot VM klases metadatu (metatelpas) atmiņu, samazina metatelpas nospiedumu un vienkāršo metatelpas kodu, lai samazinātu uzturēšanas izmaksas. Metaspace ir bijušas problēmas ar lielu atmiņas izmantošanu ārpus kaudzes. Plāns prasa aizstāt esošo atmiņas sadalītāju ar draugu bāzes sadalījuma shēmu, nodrošinot algoritmu atmiņas sadalīšanai starpsienās, lai apmierinātu atmiņas pieprasījumus. Šī pieeja ir izmantota tādās vietās kā Linux kodols, un tas praktiski piešķirs atmiņu mazākos gabalos, lai samazinātu klases iekrāvēju pieskaitāmās izmaksas. Sadrumstalotība arī tiks samazināta. Turklāt operētājsistēmas atmiņas saistība ar atmiņas pārvaldības laukumiem tiks veikta slinki un pēc pieprasījuma, lai samazinātu iekrāvēju nospiedumu, kas sāk darboties ar lielām arēnām, bet tos neizmanto uzreiz vai, iespējams, neizmanto pilnībā. Lai pilnībā izmantotu elastību, ko piedāvā draugu piešķiršana, metatelpas atmiņa tiks sakārtota vienāda lieluma granulās, kuras var piešķirt un neizpildīt neatkarīgi viens no otra.
• C ++ 14 valodas funkciju iespējošana, lai ļautu izmantot C ++ 14 iespējas JDK C ++ pirmkodā un sniegtu īpašus norādījumus par to, kuras no šīm funkcijām var izmantot HotSpot VM kodā. Izmantojot JDK 15, valodas funkcijas, kuras C ++ kods izmanto JDK, ir ierobežotas līdz valodas standartiem C ++ 98/03. Izmantojot JDK 11, pirmkods tika atjaunināts, lai atbalstītu būvēšanu ar jaunākām C ++ standarta versijām. Tas ietver iespēju veidot ar jaunākajām kompilatoru versijām, kas atbalsta C ++ 11/14 valodas funkcijas. Šis priekšlikums neierosina stila vai lietošanas izmaiņas C ++ kodam, kas tiek izmantots ārpus HotSpot. Bet, lai izmantotu C ++ valodas iespējas, ir nepieciešamas dažas būvēšanas laika izmaiņas, atkarībā no platformas kompilatora.
• Vektora API inkubatora stadijā, kurā JDK būtu aprīkots ar inkubatora moduli, jdk.inkubators.vektors, lai izteiktu vektoru aprēķinus, kas apkopoti optimālām vektoru aparatūras instrukcijām atbalstītajās CPU arhitektūrās, lai sasniegtu izcilu sniegumu līdzvērtīgiem skalāriem aprēķiniem. Vektoru API nodrošina mehānismu sarežģītu vektoru algoritmu rakstīšanai Java, vektorizācijai izmantojot jau esošu atbalstu HotSpot VM, bet ar lietotāja modeli, kas padara vektorizāciju paredzamāku un izturīgāku. Priekšlikuma mērķi ietver skaidras un kodolīgas API nodrošināšanu, lai izteiktu vektoru aprēķinu diapazonu, ir platformas agnostisks, atbalstot vairākas CPU arhitektūras, kā arī uzticamu izpildlaika apkopošanu un veiktspēju x64 un AArch64 arhitektūrās. Gracioza degradācija ir arī mērķis, kurā vektora aprēķins graciozi degradējas un joprojām darbojas, ja to izpildes laikā nevar pilnībā izteikt kā aparatūras vektoru instrukciju secību vai nu tāpēc, ka arhitektūra neatbalsta dažas instrukcijas vai netiek atbalstīta cita procesora arhitektūra .
• JDK pārnešana uz Windows / AArch64 platformu. Izlaižot jaunu serveru klases un patērētāju AArch64 (ARM64) aparatūru, pieprasījuma dēļ Windows / AArch64 ir kļuvusi par nozīmīgu platformu. Kaut arī pati pārnešana jau ir pilnībā pabeigta, šī priekšlikuma uzmanības centrā ir ostas integrācija galvenajā JDK krātuvē.
• JDK pārnešana uz Alpine Linux un citiem Linux izplatījumiem, kas kā musulmaņu primāro C bibliotēku izmanto x64 un AArch64 arhitektūrās. Musl ir Linux bibliotēkas standarta funkcionalitātes ieviešana, kas aprakstīta ISO C un Posix standartos. Alpine Linux ir maza attēla izmēra dēļ plaši izplatīts mākoņu izvietošanā, mikropakalpojumos un konteineru vidēs. Docker attēls operētājsistēmai Linux ir mazāks par 6 MB. Ļaujot Java šādos iestatījumos darboties bez izvēles, Tomcat, Jetty, Spring un citi populāri ietvari ļaus dabiski darboties šajās vidēs. Izmantojot jlink, lai samazinātu Java izpildlaika lielumu, lietotājs var izveidot vēl mazāku attēlu, kas pielāgots konkrētas lietojumprogrammas darbināšanai.
• Nodrošinot ierakstu klases, kas darbojas kā nemainīgu datu pārredzami nesēji. Ierakstus var uzskatīt par nominālajiem skaitļiem. Ieraksti tika priekšskatīti JDK 14 un JDK 15. Šie centieni ir atbilde uz sūdzībām, ka Java ir bijusi pārāk izteiksmīga vai pārāk daudz ceremoniju. Plāna mērķi ietver objektorientētas konstrukcijas izstrādi, kas izsaka vienkāršu vērtību apkopojumu, palīdzot izstrādātājiem koncentrēties uz nemaināmu datu modelēšanu, nevis uz paplašināmu uzvedību, automātiski ieviešot ar datiem pamatotas metodes, piemēram, ir vienāds un piekļuves iespējas, kā arī saglabājot ilgstošus Java principus, piemēram, nominālo rakstīšanu.
• Unix domēna kontaktligzdu kanālu pievienošana, kuros ligzdu kanālu un serveru ligzdu kanālu API tiek pievienoti Unix domēna (AF_UNIX) ligzdas atbalsts paketē nio.channels. Plāns arī paplašina mantoto kanālu mehānismu, lai atbalstītu Unix domēna kontaktligzdu kanālus un serveru ligzdu kanālus. Unix domēna kontaktligzdas tiek izmantotas starpprocesu saziņai tajā pašā resursdatorā. Tās vairumā gadījumu ir līdzīgas TCP / IP ligzdām, izņemot to, ka tās adresē failu sistēmas ceļa nosaukumi, nevis IP adreses un porta numuri. Jaunās iespējas mērķis ir atbalstīt visas Unix domēna ligzdu kanālu funkcijas, kas ir izplatītas lielākajās Unix platformās un Windows. Unix domēna kontaktligzdu kanāli rīkosies tāpat kā esošie TCP / IP kanāli lasīšanas / rakstīšanas uzvedības, savienojuma iestatīšanas, ienākošo savienojumu pieņemšanas serveru ziņā un multipleksēšanas ar citiem neabloķējošiem atlasāmajiem kanāliem atlasītājā. Unix domēna ligzdas ir drošākas un efektīvākas nekā TCP / IP atgriezeniskās saites vietējai starpprocesu komunikācijai.
• Ārzemju atmiņas piekļuves API, kas ļauj Java programmām droši piekļūt svešai atmiņai ārpus Java kaudzes. Iepriekš inkubēts gan JDK 14, gan JDK 15, svešās atmiņas piekļuves API tiks atkārtoti inkubēts JDK 16, pievienojot precizējumus. Veiktas izmaiņas, tostarp skaidrāka lomu nodalīšana starp MemorySegment un Atmiņas adreses saskarnes. Šī priekšlikuma mērķi ietver viena API nodrošināšanu, lai darbotos ar dažāda veida svešo atmiņu, ieskaitot vietējo, pastāvīgo un pārvaldīto kaudzes atmiņu. API nevajadzētu graut JVM drošību. Motivē priekšlikumu, ka daudzām Java programmām ir piekļuve svešai atmiņai, piemēram, Ignite, Memcached un MapDB. Bet Java API nenodrošina apmierinošu risinājumu piekļuvei svešai atmiņai.
• Raksta atbilstība instanceof operatoru, kas arī tika priekšskatīts gan JDK 14, gan JDK 15. Tas tiks pabeigts JDK 16. Pattern matching ļauj programmas kopējo loģiku, proti, komponentu nosacītu iegūšanu no objektiem, izteikt kodolīgāk un drošāk.
• Jpackage rīka nodrošināšana autonomu Java lietojumprogrammu iesaiņošanai. Jpackage, kas tika ieviests kā inkubācijas rīks JDK 14, jpackage palika inkubācijā JDK 15. Ar JDK 16 jpackage pāriet uz ražošanu, atbalstot vietējos pakotņu formātus, lai lietotājiem sniegtu dabisku instalēšanas pieredzi un ļautu iepakojuma laikā norādīt palaišanas laika parametrus. Formāti ietver msi un exe operētājsistēmā Windows, pkg un dmg operētājsistēmā MacOS un deb un rpm operētājsistēmā Linux. Rīku var izsaukt tieši no komandrindas vai programmatiski. Jaunais iepakojuma rīks risina situāciju, kad daudzas Java lietojumprogrammas ir jāinstalē vietējās platformās pirmās klases veidā, nevis jānovieto uz klases vai moduļa ceļa. Nepieciešama instalējama pakete, kas piemērota vietējai platformai.
• OpenJDK pirmkodu krātuvju migrēšana no Mercurial uz Git. Šīs pūles ir priekšrocības versiju vadības sistēmas metadatu lielumā, pieejamajos rīkos un mitināšanā.
• Migrācija uz GitHub, kas saistīta ar migrāciju no Mercurial-to-Git, un JDK 16 pirmkodu krātuvēm jābūt populārajā koda koplietošanas vietnē. JDK funkciju izlaidumi un JDK atjauninājumu izlaidumi Java 11 un jaunākām versijām būtu daļa no šī plāna. Mercurial JDK un JDK-sandbox pāreja uz Git, GitHub un Skara tika veikta 5. septembrī un ir atvērta ieguldījumiem.

Agrīnās piekļuves JDK 16 versijas Linux, Windows un MacOS ir atrodamas vietnē jdk.java.net. Tāpat kā JDK 15, arī JDK 16 būs īstermiņa laidiens, kuru atbalstīs sešus mēnešus. JDK 17, kura termiņš ir 2021. gada septembris, būs ilgtermiņa atbalsta (LTS) izlaidums, kas saņems vairāku gadu atbalstu. Pašreizējais LTS izlaidums JDK 11 tika izlaists 2018. gada septembrī.