JDK 16: Java 16: n uudet ominaisuudet

Java Development Kit (JDK) 16 on saavuttanut aloitusvaiheensa, mikä tarkoittaa, että ominaisuusjoukko on nyt jäädytetty 10. joulukuuta 2020 lähtien. JDK 16: n uudet ominaisuudet vaihtelevat suljettujen luokkien toisesta esikatselusta kuvioiden sovittamiseen samanaikaisiin säikeisiin - pinon käsittely jätteiden keräämiseksi.

JDK 16 on Java-vakioversion viitetoteutus, joka on asetettu seuraamaan 15. syyskuuta saapunutta JDK 15: tä, joka saapui 15. syyskuuta. Ehdotetussa julkaisuaikataulussa JDK 16 on saavuttanut toisen ramppausvaiheen 14. tammikuuta 2021, minkä jälkeen julkaisuhakemukset saapuvat 4. helmikuuta ja 18. helmikuuta 2021. Tuotantojulkaisu on tarkoitus julkaista 16. maaliskuuta 2021.

Seitsemäntoista ehdotusta kohdistuu virallisesti JDK 16: een 10. joulukuuta 2020 alkaen. Java 16: n uusia ominaisuuksia ovat:

• Arvopohjaisten luokkien ehdotuksen varoitukset nimeävät primitiiviset käärintäluokat arvopohjaisiksi ja hylkäävät niiden rakentajat poistamista varten, mikä aiheuttaa uusia poistovaroituksia. Varoituksia virheellisistä yrityksistä synkronoida Java-alustan arvopohjaisten luokkien esiintymissä. Tätä vaivaa ajaa Valhalla-projekti, joka pyrkii merkittävästi parantamaan Java-ohjelmointimallia primitiivisten luokkien muodossa. Primitiiviset luokat julistavat esiintymät identiteettivapaiksi ja kykeneviksi inline- tai litistettyihin esityksiin, joissa esiintymiä voidaan kopioida vapaasti muistipaikkojen välillä ja koodata käyttämällä instanssien kenttien arvoja. Java-primitiivisten luokkien suunnittelu ja toteutus on nyt riittävän kypsää, jotta tiettyjen Java-alustan luokkien siirtyminen primitiivisiin luokkiin voidaan ennakoida tulevassa julkaisussa. Siirtymisen ehdokkaat on epävirallisesti nimetty arvoperusteisiksi luokiksi API-määrityksissä.
• Aikaisemmin esikatseltu JDK 15: ssä, sinetöidyt luokat ja rajapinnat rajoittavat muita luokkia ja rajapintoja, jotka voivat laajentaa tai toteuttaa niitä. Suunnitelman tavoitteisiin kuuluu luokan tai käyttöliittymän kirjoittajan salliminen hallita koodin toteuttamisesta vastaavaa koodia, tarjota selventävämpi tapa kuin pääsymuuttujat rajoittaa yliluokan käyttöä ja tukea tulevia ohjeita mallien sovittamisessa tarjoamalla perusta mallien analysointi.
• JDK: n sisäisten komponenttien voimakas kapselointi oletuksena, paitsi kriittiset sisäiset sovellusliittymät, kuten väärin. vaarallinen. Käyttäjät voivat valita rennon ja vahvan kapseloinnin, joka on ollut oletusarvo JDK 9: n jälkeen. Tämän ehdotuksen tavoitteisiin kuuluu JDK: n turvallisuuden ja ylläpidettävyyden parantaminen osana Project Jigsaw -ohjelmaa ja kannustaminen kehittäjiä siirtymään sisäisten elementtien käytöstä tavallisten sovellusliittymien käyttöön, jotta että sekä kehittäjät että loppukäyttäjät voivat päivittää helposti uusiin Java-julkaisuihin. Tämä ehdotus aiheuttaa ensisijaisen riskin siitä, että olemassa olevaa Java-koodia ei voida suorittaa. Kehittäjiä kehotetaan käyttämään jdeps-työkalua tunnistamaan koodi, joka riippuu JDK: n sisäisistä elementeistä, ja siirtymään vakiomuotoisiin korvauksiin, kun niitä on saatavilla. Kehittäjät voivat käyttää olemassa olevaa julkaisua, kuten JDK 11, testata olemassa olevaa koodia käyttämällä--illegal-access = varoita tunnistaa sisäiset elementit, joihin pääsee heijastuksen avulla--illegal-access = virheenkorjaus virheellisen koodin löytämiseksi ja testaaminen --illegal-access = kieltää.
• Ulkomaisten linkkien sovellusliittymä, joka tarjoaa staattisesti kirjoitetun, Java-pääsyn natiivikoodiin. Tämä sovellusliittymä on inkubaattorivaiheessa JDK 16: ssa. Yhdessä ehdotetun ulkomaisen muistin käyttöliittymän kanssa ulkomaisten linkkien sovellusliittymä yksinkertaistaa huomattavasti muuten virheille alttiita natiivikirjastoon sitoutumisen prosesseja. Tämän suunnitelman on tarkoitus korvata JNI (Java Native Interface) erinomaisella puhtaalla Java-kehitysmallilla, tarjota C-tukea ja ajan mittaan olla riittävän joustava tukemaan muita alustoja, kuten 32-bittinen x86, ja vieraat toiminnot, jotka on kirjoitettu muilla kielillä kuin C, kuten C ++. Suorituskyvyn tulisi olla parempi tai verrattavissa JNI: hen.
• ZGC (Z Garbage Collector) -säikeenkäsittely siirretään turvapisteistä samanaikaiseen vaiheeseen. Tämän suunnitelman tavoitteisiin kuuluu säiepinon käsittelyn poistaminen ZGC-turvapisteistä; pinonkäsittelyn tekeminen laiskaksi, yhteistyöhön, samanaikaiseksi ja inkrementaaliseksi; poistetaan kaikki muut langankohtaiset juuriprosessit ZGC-turvapisteistä; ja järjestetään mekanismi muille HotSpot VM -alijärjestelmille pinon käsittelyyn. ZGC: n on tarkoitus tehdä GS-taukoista ja skaalautuvuusongelmista HotSpotissa menneisyyttä. Toistaiseksi GC-toiminnot, jotka skaalautuvat kasan koon ja metatilan kanssa, on siirretty pois turvapisteoperaatioista samanaikaisiin vaiheisiin. Näitä ovat olleet merkinnät, uudelleensijoittaminen, viitteiden käsittely, luokan purkaminen ja suurin osa juurien käsittelystä. Ainoat toiminnot, joita vielä tehdään GC-turvapisteissä, ovat juuriprosessoinnin osajoukko ja aikarajoitettu merkinnän lopetusoperaatio. Nämä juuret ovat olleet Java-säiepinoja ja muita ketjujuuria, joiden juuret ovat ongelmallisia, koska ne skaalautuvat säikeiden lukumäärän kanssa. Jos haluat siirtyä nykyisestä tilanteesta pidemmälle, lankakohtainen käsittely, pinon skannaus mukaan lukien, on siirrettävä samanaikaiseen vaiheeseen. Tämän suunnitelman mukaan parannetun viiveen siirtokustannusten tulisi olla merkityksettömiä ja ZGC-turvapisteiden sisällä vietetyn ajan tyypillisillä koneilla tulisi olla alle yksi millisekunti.
• Joustava metatilatoiminto, joka palauttaa käyttämättömän HotSpot VM-luokan metatietojen (metatilan) muistin nopeammin käyttöjärjestelmälle, vähentää metatilan tilaa ja yksinkertaistaa metatilakoodia ylläpitokustannusten pienentämiseksi. Metaspacella on ollut ongelmia runsaasti vapaata muistia käytettäessä. Suunnitelma vaatii nykyisen muistinjakajan korvaamista kaveripohjaisella allokointijärjestelmällä, joka tarjoaa algoritmin muistin jakamiseksi osioiksi muistipyyntöjen tyydyttämiseksi. Tätä lähestymistapaa on käytetty esimerkiksi Linux-ytimen kaltaisissa paikoissa, ja se tekee käytännölliseksi jakaa muistia pienempinä paloina luokan kuormaimen yleiskustannusten vähentämiseksi. Myös pirstaloituminen vähenee. Lisäksi käyttöjärjestelmän käyttömuistin sitoutuminen muistinhallinta-alueisiin tehdään laiskasti pyynnöstä, jotta voidaan vähentää kuormaajien jalanjälkeä, jotka aloittavat suurilla areenoilla, mutta eivät käytä niitä välittömästi tai eivät välttämättä käytä niitä täysimääräisesti. Kavereiden allokoinnin tarjoaman joustavuuden hyödyntämiseksi metatilamuisti järjestetään yhtenäisen kokoisiksi rakeiksi, jotka voidaan sitoa ja sitoutua toisistaan ​​riippumatta.
• C ++ 14 -kielitoimintojen käyttöönotto C ++ 14 -ominaisuuksien käytön sallimiseksi JDK C ++ -lähdekoodissa ja antaa erityisiä ohjeita siitä, mitä näistä ominaisuuksista voidaan käyttää HotSpot VM -koodissa. JDK 15: n kautta C ++ -koodin käyttämät kieliominaisuudet JDK: ssa on rajoitettu C ++ 98/03 -standardeihin. JDK 11: n avulla lähdekoodi päivitettiin tukemaan rakentamista uusilla C ++ -standardin versioilla. Tähän sisältyy mahdollisuus rakentaa uusimmilla versioilla kääntäjiltä, ​​jotka tukevat C ++ 11/14 -kielten ominaisuuksia. Tämä ehdotus ei ehdota tyyliä tai käyttömuutoksia C ++ -koodille, jota käytetään HotSpotin ulkopuolella. Mutta C ++ - kieliominaisuuksien hyödyntämiseksi tarvitaan joitain rakennusaikamuutoksia alustankääntäjästä riippuen.
• Inkubaattorivaiheessa oleva vektorirajapinta, jossa JDK olisi varustettu inkubaattorimoduulilla, jdk.inkubaattori.vektori, ilmaisemaan vektorilaskennat, jotka kootaan optimaalisiksi vektorilaitteisto-ohjeiksi tuetuissa CPU-arkkitehtuureissa, jotta saavutetaan erinomainen suorituskyky vastaaviin skalaarilaskelmiin. Vektori-sovellusliittymä tarjoaa mekanismin monimutkaisten vektori-algoritmien kirjoittamiseen Java-järjestelmään, käyttäen vektorointiin HotSpot-virtuaalikoneessa jo olemassa olevaa tukea, mutta käyttäjämallilla, joka tekee vektorisoinnista ennakoitavamman ja vankemman. Ehdotuksen tavoitteisiin kuuluu selkeän ja ytimekkään API: n tarjoaminen useiden vektorilaskelmien ilmaisemiseksi, alustan agnostiikka tukemalla useita suorittimen arkkitehtuureja ja luotettavan ajonaikaisen kokoamisen ja suorituskyvyn tarjoaminen x64- ja AArch64-arkkitehtuureille. Siro hajoaminen on myös tavoite, jossa vektorilaskenta hajoaisi sulavasti ja toimisi edelleen, jos sitä ei voida täysin ilmaista ajon aikana laitteistovektori-käskyjen sarjana joko siksi, että arkkitehtuuri ei tue joitain käskyjä tai toista CPU-arkkitehtuuria ei tueta .
• JDK: n siirtäminen Windows / AArch64-alustalle. Uuden palvelinluokan ja kuluttaja-AArch64 (ARM64) -laitteiston julkaisemisen myötä Windows / AArch64: stä on tullut tärkeä alusta kysynnän vuoksi. Itse siirto on jo pääosin valmis, mutta tämän ehdotuksen painopiste on portin integrointi JDK-päätietovarastoon.
• JDK: n siirtäminen Alpine Linuxiin ja muihin Linux-jakeluihin, jotka käyttävät muslea ensisijaisena C-kirjastona, x64- ja AArch64-arkkitehtuureilla. Musl on Linux-toteutus ISO C- ja Posix-standardeissa kuvatuista kirjaston vakiotoiminnoista. Alpine Linux on laajalti käytössä pilvipalveluissa, mikropalveluissa ja konttiympäristöissä pienen kuvakoonsa vuoksi. Docker-kuva Linuxille on pienempi kuin 6 Mt. Jos annat Java-laitteen loppua valmiista tällaisissa asetuksissa, Tomcat, Jetty, Spring ja muut suositut kehykset voivat toimia luonnollisesti näissä ympäristöissä. Pienentämällä Java-ajonaikaa jlinkin avulla käyttäjä voi luoda vielä pienemmän kuvan, joka on räätälöity tietyn sovelluksen ajamiseksi.
• Tarjotaan tietueluokit, jotka toimivat muuttumattomien tietojen läpinäkyvinä kantajina. Tietueita voidaan pitää nimellisarvoina. Tietueita esikatseltiin JDK 14: ssä ja JDK 15: ssä. Tämä pyrkimys on vastaus valituksiin, joiden mukaan Java on ollut liian sanallinen tai seremonioita. Suunnitelman tavoitteisiin kuuluu olio-suuntautuneen rakenteen laatiminen, joka ilmaisee yksinkertaisen arvoryhmän, joka auttaa kehittäjiä keskittymään muuttumattomien tietojen mallintamiseen laajennettavan käyttäytymisen sijaan, toteuttamalla automaattisesti dataan perustuvia menetelmiä, kuten on yhtä suuri ja käyttöoikeudet sekä säilyttämällä pitkäaikaiset Java-periaatteet, kuten nimellinen kirjoittaminen.
• Lisätään Unix-toimialueen kanavakanavat, joissa Unix-domain (AF_UNIX) -liitäntätuki lisätään nio.channels-paketin pistorasiakanavaan ja palvelimen pistorasiakanavan sovellusliittymiin. Suunnitelma laajentaa myös perittyä kanavamekanismia tukemaan Unix-verkkotunnuksen ja palvelimen pistorasiakanavia. Unix-verkkotunnuksen pistorasioita käytetään prosessin väliseen viestintään samalla isännällä. Ne ovat useimmiten samanlaisia ​​kuin TCP / IP-liitännät, paitsi että ne osoitetaan tiedostojärjestelmän polun nimillä eikä IP-osoitteilla ja porttien numeroilla. Uuden ominaisuuden tavoitteena on tukea kaikkia Unix-toimialueen pistorasiakanavien ominaisuuksia, jotka ovat yleisiä suurimmilla Unix-alustoilla ja Windowsissa. Unix-toimialueen pistorasiakanavat käyttäytyvät samalla tavalla kuin nykyiset TCP / IP-kanavat luku- / kirjoituskäyttäytymisen, yhteyden muodostamisen, palvelimien saapuvien yhteyksien hyväksynnän ja multipleksoinnin suhteen muiden ei-estävien valittavien kanavien kanssa. Unix-toimialueen pistorasiat ovat turvallisempia ja tehokkaampia kuin TCP / IP-takaisinkytkentäyhteydet paikallista, prosessien välistä viestintää varten.
• Vieraan muistin käyttöliittymä, jonka avulla Java-ohjelmat pääsevät turvallisesti vieraaseen muistiin Java-kasan ulkopuolella. Aikaisemmin inkuboitu sekä JDK 14: ssä että JDK 15: ssä, vieraan muistin käyttöliittymä API inkuboitiin uudelleen JDK 16: ssa lisäämällä tarkennuksia. Muutoksia on tehty, mukaan lukien roolien selvempi erottaminen Muistiosa ja Muistiosoitteet rajapinnat. Tämän ehdotuksen tavoitteisiin kuuluu yhden API: n tarjoaminen toimimaan erityyppisessä vieraassa muistissa, mukaan lukien alkuperäinen, pysyvä ja hallittu kasamuisti. API: n ei pitäisi heikentää JVM: n turvallisuutta. Ehdotuksen motivoimiseksi on, että monet Java-ohjelmat käyttävät ulkomaista muistia, kuten Ignite, Memcached ja MapDB. Mutta Java-sovellusliittymä ei tarjoa tyydyttävää ratkaisua vieraan muistin käyttämiseen.
• Kuvion vastaavuus mallille esiintymä operaattori, jota myös esikatseltiin sekä JDK 14: ssä että JDK 15: ssä. Se viimeistellään JDK 16: ssa. Kuvion sovitus mahdollistaa ohjelman yhteisen logiikan, nimittäin komponenttien ehdollisen poiminnan esineistä, ilmaisemaan ytimekkäämmästi ja turvallisemmin.
• Jpackage-työkalun tarjoaminen itsenäisten Java-sovellusten pakkaamiseen. Jpackage esiteltiin inkubointityökaluna JDK 14: ssä, ja jpackage pysyi inkubaatiossa JDK 15: ssä. JDK 16: n kanssa jpackage siirtyy tuotantoon tukemalla natiivipakettimuotoja, jotta käyttäjät saisivat luonnollisen asennuskokemuksen ja mahdollistaisivat käynnistysajan parametrien määrittämisen pakkaushetkellä. Muotoja ovat msi ja exe Windowsissa, pkg ja dmg MacOS: ssa sekä deb ja rpm Linuxissa. Työkalu voidaan kutsua suoraan komentoriviltä tai ohjelmallisesti. Uusi pakkaustyökalu käsittelee tilannetta, jossa monet Java-sovellukset on asennettava alkuperäisille alustoille ensiluokkaisella tavalla sen sijaan, että ne sijoitettaisiin luokan tai moduulin polulle. Tarvitaan natiiville alustalle sopiva asennettava paketti.
• OpenJDK-lähdekoodivarastojen siirtäminen Mercurialista Gitiin. Tämän työn edistäminen on etuja versionhallintajärjestelmän metatietojen koossa, käytettävissä olevissa työkaluissa ja isännöinnissä.
• Siirtyminen GitHubiin, joka liittyy Mercurial-to-Git-migraatioon, ja JDK 16-lähdekoodivarastot ovat suositussa koodinjakosivustossa. JDK-ominaisuusjulkaisut ja Java 11: n ja sitä uudempien JDK-päivitysten julkaisut olisivat osa tätä suunnitelmaa. Mercurial JDK: n ja JDK-hiekkalaatikon siirtyminen Gitiin, GitHubiin ja Skaraan tehtiin 5. syyskuuta, ja siihen voi osallistua.

JDK 16: n varhainen käyttöoikeusrakenne Linuxille, Windowsille ja MacOS: lle löytyy osoitteesta jdk.java.net. Kuten JDK 15, JDK 16 on lyhytaikainen julkaisu, jota tuetaan kuuden kuukauden ajan. JDK 17, määräpäivä syyskuussa 2021, on pitkäaikaisen tuen (LTS) julkaisu, joka saa useita vuosia tukea. Nykyinen LTS-julkaisu, JDK 11, julkaistiin syyskuussa 2018.