Java izstrādes komplekts 15, Oracle nākamās Java SE (Standard Edition) versijas ieviešana, būs pieejams kā ražošanas izlaidums šodien, 2020. gada 15. septembrī. JDK 15 galvenās iezīmes ir teksta bloki, slēptās klases, svešas atmiņas piekļuves API, Z atkritumu savācējs un aizzīmogotu klašu priekšskatījumi, modeļu saskaņošana un ieraksti.
JDK 15 ir tikai īstermiņa izlaidums, un to sešus mēnešus atbalsta tikai Oracle Premier Support, līdz nākamā gada martā ieradīsies JDK 16. JDK 17, nākamais ilgtermiņa atbalsta izlaidums, kuru Oracle atbalsta astoņus gadus, ir paredzēts, ka tas nonāks pēc gada, kā paredzēts Oracle sešu mēnešu izlaiduma kadencē Java SE versijām.
Izstrādātāji tagad var apskatīt JDK 15, lai iegūtu priekšstatu par to, kas būs JDK 17, sacīja Oracle Java Platform Group prezidents Žoržs Zābs. Pašreizējais LTS izlaidums ir JDK 11, kas nonāca 2018. gada septembrī. LTS laidieni tiek piegādāti ik pēc trim gadiem. JDK 15 seko JDK 14, kas tika izlaists 2020. gada 17. martā.
Jaunās OpenJDK 15 funkcijas un izmaiņas:
- Otrs svešās atmiņas piekļuves API inkubators, kas ļautu Java programmām droši un efektīvi piekļūt svešai atmiņai ārpus Java kaudzes. API jāspēj darboties ar dažāda veida svešām atmiņām, piemēram, vietējo, pastāvīgo un pārvaldīto kaudzi. Daudzas Java programmas piekļūst svešai atmiņai, piemēram, Ignite un MapDB. API palīdzēs izvairīties no izmaksām un neparedzamības, kas saistītas ar atkritumu savākšanu, koplietot atmiņu visos procesos, kā arī sērijveidot un deserializēt atmiņas saturu, kartējot failus atmiņā. Java API pašlaik nenodrošina apmierinošu risinājumu piekļuvei svešai atmiņai. Bet ar jauno priekšlikumu API nevajadzētu būt iespējai graut JVM drošību. Šī spēja piedzīvo agrāku inkubatora fāzi JDK 14, ar uzlabojumiem, kas piedāvāti JDK 15.
- Aizzīmogotu klašu priekšskatījums. Kopā ar saskarnēm aizzīmogotās klases ierobežo to, kuras citas klases vai saskarnes tos var paplašināt vai ieviest. Šīs funkcijas mērķi ir ļaut klases vai saskarnes autoram kontrolēt, kurš kods ir atbildīgs 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 modeļu saskaņošanas virzienus, atbalstot izsmeļošo modeļu analīze.
- Avota koda noņemšana un būvniecības atbalsts Solaris / SPARC, Solaris / x64 un Linux / SPARC portiem, kuru noņemšana JDK 14 tika pārtraukta ar nolūku tos noņemt nākamajā laidienā. Daudziem izstrādes projektiem un funkcijām, piemēram, Valhallai, Loomam un Panamai, ir nepieciešamas būtiskas izmaiņas CPU arhitektūrā un operētājsistēmai raksturīgajā kodā. Atceļot atbalstu Solaris un SPARC portiem, OpenJDK kopienas dalībnieki varēs paātrināt jaunu funkciju izstrādi, kas virzīs platformu uz priekšu. Gan Solaris, gan SPARC pēdējos gados ir aizstājuši Linux OS un Intel procesori.
- Ieraksti, kas ir klases, kas darbojas kā nemainīgu datu pārredzami nesēji, tiks iekļauti otrajā JDK 15 priekšskatījuma versijā pēc debitēšanas kā agrīna priekšskatījuma versijā JDK 14. Plāna mērķi ietver objektorientētas konstrukcijas izstrādi, kas izsaka vienkārša vērtību apkopošana, palīdzot programmētājiem koncentrēties uz nemaināmu datu modelēšanu, nevis uz paplašināmu rīcību, automātiski ieviešot ar datiem pamatotas metodes, piemēram, vienādus un vērtētājus, un saglabājot tādus ilgstošus Java principus kā nominālo tipēšanu un migrācijas savietojamību. Ierakstus var uzskatīt par nominālajiem skaitļiem.
- Kriptogrāfiskie paraksti, kuru pamatā ir Edvards-Līknes digitālā paraksta algoritms (EdDSA). EdDSA ir moderna eliptiskas līknes shēma ar priekšrocībām salīdzinājumā ar esošajām parakstu shēmām JDK. EdDSA tiks ieviesta tikai SunEC nodrošinātājā. EdDSA ir pieprasīts uzlabotas drošības un veiktspējas dēļ, salīdzinot ar citām parakstu shēmām; tas jau tiek atbalstīts šifrēšanas bibliotēkās, piemēram, OpenSSL un BoringSSL.
- Atjaunojot mantoto DatagramSocket API, aizstājot
java.net.datagram.Socketunjava.net.MulticastSocketAPI ar vienkāršākām un modernākām ieviešanām, kuras 1. ir viegli atkļūdot un uzturēt, un 2. darbojas ar virtuālajiem pavedieniem, kas pašlaik tiek pētīti projektā Loom. Jaunais plāns ir turpinājums JDK uzlabošanas 353. priekšlikumam, kas atjaunoja mantoto Socket API. Pašreizējā programmas ieviešanajava.net.datagram.Socketunjava.net.MulticastSocketdatums datēts ar JDK 1.0 un laiku, kad IPv6 vēl tika izstrādāts. Tādējādi pašreizējā programmas īstenošanaMulticastSocketmēģina saskaņot IPv4 un IPv6 grūti uzturējamos veidos. - Pēc noklusējuma tiek atspējota neobjektīva bloķēšana un tiek atceltas visas saistītās komandrindas opcijas. Mērķis ir noteikt nepieciešamību turpināt atbalstīt neobjektīvās bloķēšanas dārgi uzturējamo mantoto sinhronizācijas optimizāciju, kas tiek izmantota HotSpot virtuālajā mašīnā, lai samazinātu netīšas bloķēšanas pieskaitāmās izmaksas. Lai gan dažās Java lietojumprogrammās var novērot regresijas veiktspēju ar atspējotu bloķētu bloķēšanu, neobjektīvās bloķēšanas veiktspējas pieaugums parasti ir mazāk acīmredzams nekā agrāk.
- Otrais modeļa atbilstības priekšskatījums
instanceof, sekojot iepriekšējam JDK 14 priekšskatījumam. Šablonu atbilstība ļauj vienkāršāk un kodolīgāk izteikt programmas kopējo loģiku, galvenokārt nosacītu komponentu iegūšanu no objektiem. Tādas valodas kā Haskell un C # ir izmantojušas modeļu atbilstību tā īsumam un drošībai. - Slēptās klases, t.i., klases, kuras citu klašu baitkods nevar tieši izmantot, ir paredzētas izmantošanai ietvaros, kas izpildes laikā ģenerē klases un izmanto tos netieši, izmantojot refleksiju. Slēpto klasi var definēt kā piekļuves kontroles ligzdas dalībnieku, un to var izkraut neatkarīgi no citām klasēm. Priekšlikums uzlabotu visu JVM valodu efektivitāti, ļaujot standarta API noteikt slēptās klases, kuras nav atrodamas un kurām ir ierobežots dzīves cikls. Rāmji JDK iekšienē un ārpus tām spētu dinamiski ģenerēt klases, kas tā vietā varētu definēt slēptās klases. Daudzas valodas, kas balstītas uz JVM, elastības un efektivitātes dēļ paļaujas uz dinamisku klases ģenerēšanu. Šī priekšlikuma mērķi ir šādi: ļaut ietvariem definēt klases kā neatklājamas ietvara ieviešanas detaļas, tāpēc citas klases nevar tās sasaistīt vai atklāt, pārdomājot; atbalsts piekļuves kontroles ligzdas paplašināšanai ar klasēm, kuras nav atrodamas; un atbalsts neatklājamu klašu agresīvai izkraušanai, tāpēc ietvari var elastīgi noteikt tik daudz, cik nepieciešams. Vēl viens mērķis ir nestandarta API novecošana,
misc.Unsafe :: defineAnonymousClass, ar nolūku atcelt noņemšanu turpmākajā laidienā. Turklāt šī priekšlikuma rezultātā Java valoda nav jāmaina. - Saskaņā ar šo priekšlikumu Z atkritumu savācējs (ZGC) pabeidz produkta eksperimentālo funkciju. Integrēts JDK 11, kas ieradās 2018. gada septembrī, ZGC ir mērogojams, zemas aiztures atkritumu savācējs. ZGC tika ieviesta kā eksperimentāla iespēja, jo Java izstrādātāji nolēma, ka šāda lieluma un sarežģītības iezīme jāievieš uzmanīgi un pakāpeniski. Kopš tā laika ir pievienoti vairāki uzlabojumi, sākot no vienlaicīgas klases izkraušanas, neizmantotas atmiņas atcelšanas un klases datu koplietošanas atbalsta līdz uzlabotai NUMA izpratnei un daudzvītņainai kaudzes iepriekšējai pieskaršanai. Arī maksimālais kaudzes lielums ir palielināts no četriem terabaitiem līdz 16 terabaitiem. ZGC risina veiktspējas problēmas lietojumprogrammās, kas saistītas ar lielu datu apjomu, piemēram, mašīnmācīšanos, kur lietotāji vēlas būt pārliecināti, ka atkritumu savākšanas dēļ datu apstrāde netiks pakļauta neprognozējamībai vai ilgām pauzēm. Atbalstītās platformas ietver Linux, Windows un MacOS.
- Teksta bloki, kas priekšskatīti gan JDK 14, gan JDK 13, ir paredzēti, lai vienkāršotu Java programmu rakstīšanas uzdevumu, atvieglojot virkņu izteikšanu, kas aptver vairākas avota koda rindas, vienlaikus izvairoties no aizbēgšanas sekvencēm parastos gadījumos. Teksta bloks ir daudzrindu virknes literālis, kas ļauj izvairīties no lielākās daļas aizbēgšanas secību, automātiski formatē virkni paredzamā veidā un piedāvā izstrādātājam iespēju kontrolēt formātu, ja nepieciešams. Teksta bloku priekšlikuma mērķis ir uzlabot Java programmu virkņu lasāmību, kas apzīmē kodu, kas rakstīts valodās, kas nav Java valodas. Vēl viens mērķis ir atbalstīt migrāciju no stīgu literāliem, nosakot, ka jebkurš jauns konstruktors var izteikt to pašu virkņu kopu kā virknes literāls, interpretēt tās pašas aizbēgšanas sekvences un ar tām var manipulēt tādā pašā veidā kā virknes literālis. OpenJDK izstrādātāji cer pievienot aizbēgšanas secības, lai pārvaldītu skaidru atstarpi un jaunās līnijas vadību.
- Shenandoah atkritumu savācējs ar nelielu pārtraukuma laiku kļūtu par ražošanas funkciju un izkļūtu no eksperimenta stadijas. Tas bija integrēts JDK 12 pirms gada.
- Nashorn noņemšana, kas 2014. gada martā debitēja JDK 8, bet kopš tā laika tādas tehnoloģijas kā GraalVM ir novecojušas. OpenJDK 15 priekšlikums aicina noņemt Nashorn API un jjs komandrindas rīku, ko izmanto Nashorn izsaukšanai.
- RMI aktivizēšanas mehānisma novecošana turpmākai noņemšanai. RMI aktivizācijas mehānisms ir novecojusi RMI daļa, kas kopš Java 8 nav obligāta. RMI aktivizēšana uzliek pastāvīgu uzturēšanas slogu. Neviena cita RMI daļa netiks novecojusi.
