JDK 15: Nove značajke u Javi 15

Java Development Kit 15, Oracleova implementacija sljedeće verzije Java SE (Standard Edition), postaje dostupan kao produkcijsko izdanje danas, 15. rujna 2020. Značajke JDK 15 uključuju blokove teksta, skrivene klase, API za pristup stranoj memoriji, Z Garbage Collector, te preglede zapečaćenih klasa, podudaranje uzoraka i zapise.

JDK 15 samo je kratkotrajno izdanje, koje će podržavati Oracle Premier Support šest mjeseci dok JDK 16 ne stigne sljedećeg ožujka. JDK 17, sljedeće izdanje za dugoročnu podršku, koje će Oracle podržavati osam godina, predviđeno je da stigne za godinu dana, prema Oraclovom šestomjesečnom ritmu izdanja za verzije Java SE.

Programeri sada mogu pogledati JDK 15 kako bi dobili ideju o tome što će biti u JDK 17, rekao je Georges Saab, predsjednik Oracleove Java Platform Group. Trenutno LTS izdanje je JDK 11, koje je stiglo u rujnu 2018. LTS izdanja stižu svake tri godine. JDK 15 slijedi JDK 14, koji je objavljen 17. ožujka 2020. 

Nove značajke i promjene u OpenJDK 15:

  • Drugi inkubator API-ja za pristup stranoj memoriji, koji bi Java programima omogućio siguran i učinkovit pristup stranoj memoriji izvan Java gomile. API bi trebao moći raditi na raznim vrstama strane memorije, poput izvorne, postojane i upravljane hrpe. Mnogi Java programi pristupaju stranoj memoriji, poput Ignite i MapDB. API bi pomogao izbjeći troškove i nepredvidivost povezani sa skupljanjem smeća, podijeliti memoriju između procesa i serializirati i deserializirati memorijski sadržaj mapiranjem datoteka u memoriju. Java API trenutno ne nudi zadovoljavajuće rješenje za pristup stranoj memoriji. No, s novim prijedlogom ne bi trebalo biti moguće da API potkopa sigurnost JVM-a. Ova sposobnost prolazi kroz raniju fazu inkubatora u JDK 14, s poboljšanjima koja su ponuđena u JDK 15. 
  • Pregled zapečaćenih klasa. Zajedno sa sučeljima, zatvorene klase ograničavaju koje ih druge klase ili sučelja mogu proširiti ili implementirati. Ciljevi ove značajke uključuju omogućavanje autoru klase ili sučelja da kontrolira koji je kôd odgovoran za njegovu primjenu, pružaju deklarativniji način od modifikatora pristupa da ograniče upotrebu superklase i podržavaju buduće upute u podudaranju uzoraka podupirući iscrpne analiza uzoraka.
  • Uklanjanje izvornog koda i podrška za izgradnju portova Solaris / SPARC, Solaris / x64 i Linux / SPARC, koji su prestali biti uklonjeni u JDK 14 s namjerom da ih uklone u budućem izdanju. Mnogi projekti i značajke u razvoju kao što su Valhalla, Loom i Panama zahtijevaju značajne promjene u CPU arhitekturi i kodu specifičnom za operativni sustav. Ispuštanje podrške za Solaris i SPARC priključke omogućit će suradnicima OpenJDK zajednice da ubrzaju razvoj novih značajki koje će pomaknuti platformu naprijed. I Solaris i SPARC posljednjih su godina zamijenjeni Linux OS-om i Intel procesorima.
  • Zapisi, koji su klase koje djeluju kao transparentni nosači nepromjenjivih podataka, bit će uključeni u drugu inačicu pregleda u JDK 15, nakon što će debitirati kao rani pregled u JDK 14. Ciljevi plana uključuju osmišljavanje objektno orijentirane konstrukcije koja izražava jednostavno agregiranje vrijednosti, pomažući programerima da se usredotoče na modeliranje nepromjenjivih podataka, a ne na proširivo ponašanje, automatskom primjenom metoda vođenih podacima kao što su jednakosti i procjenitelji, te očuvanjem dugotrajnih Java principa poput nominalnog tipkanja i kompatibilnosti migracija. Zapisi se mogu smatrati nominalnim korijenima. 
  • Kriptografski potpisi na temelju Edwards-Curve algoritma digitalnog potpisa (EdDSA). EdDSA je moderna shema eliptičke krivulje s prednostima u odnosu na postojeće sheme potpisa u JDK. EdDSA će se implementirati samo u SunEC dobavljaču. EdDSA je tražen zbog svoje poboljšane sigurnosti i performansi u usporedbi s drugim shemama potpisa; već je podržan u kripto knjižnicama kao što su OpenSSL i BoringSSL.
  • Reimplementacija naslijeđenog API-ja DatagramSocket zamjenom temeljnih implementacija  API-ja java.net.datagram.Socketi java.net.MulticastSocketAPI-ja jednostavnijim i modernijim implementacijama koje su 1. jednostavne za otklanjanje pogrešaka i održavanje i 2. rade s virtualnim nitima koje se trenutno istražuju u Project Loomu. Novi plan je nastavak prijedloga za poboljšanje JDK 353 koji je ponovno primijenio naslijeđeni API Socket. Trenutne implementacije java.net.datagram.Socketi java.net.MulticastSocketdatiraju iz JDK 1.0 i vremena kada je IPv6 još uvijek bio u fazi izrade . Stoga trenutna implementacija  MulticastSocket pokušava uskladiti IPv4 i IPv6 na načine koje je teško održati.
  • Onemogućeno pristrano zaključavanje prema zadanim postavkama i odbacivanje svih povezanih opcija naredbenog retka. Cilj je utvrditi potrebu za kontinuiranom podrškom skupe za održavanje naslijeđene optimizacije sinkronizacije pristranog zaključavanja, koja se koristi u virtualnom stroju HotSpot za smanjenje neograničenog zaključavanja. Iako neki Java programi mogu zabilježiti regresiju u izvedbi s onemogućenim pristranim zaključavanjem, dobici u izvedbi pristranog zaključavanja uglavnom su manje očigledni nego nekada.
  • Drugi pregled podudaranja uzoraka za instanceof, nakon prethodnog pregleda u JDK 14. Podudaranje uzoraka omogućuje zajedničku logiku u programu, uglavnom uvjetno izdvajanje komponenata iz objekata, da se izrazi lakše i sažetije. Jezici poput Haskell i C # prihvatili su podudaranje uzoraka zbog svoje kratkoće i sigurnosti.
  • Skrivene klase, tj. Klase koje se ne mogu izravno koristiti bytecodeom drugih klasa, namijenjene su okvirima koji generiraju klase tijekom izvođenja i koji ih neizravno koriste refleksijom. Skrivena klasa može se definirati kao član gnijezda kontrole pristupa i može se istovariti neovisno o drugim klasama. Prijedlog bi poboljšao učinkovitost svih jezika na JVM-u omogućavanjem standardnog API-ja da definira skrivene klase koje se ne mogu otkriti i imaju ograničeni životni ciklus. Okviri unutar i izvan JDK-a mogli bi dinamički generirati klase koje bi umjesto toga mogle definirati skrivene klase. Mnogi jezici izgrađeni na JVM-u oslanjaju se na dinamičko generiranje klasa radi fleksibilnosti i učinkovitosti. Ciljevi ovog prijedloga uključuju: omogućavanje okvira da definiraju klase kao neotkrivene detalje implementacije okvira,tako da ih druge klase ne mogu povezati niti otkriti razmišljanjem; podrška za proširivanje gnijezda kontrole pristupa s neotkrivenim klasama; i podrška za agresivno rasterećenje klasa koje se ne mogu otkriti, tako da okviri imaju fleksibilnost da definiraju koliko god je potrebno. Drugi je cilj odbacivanje nestandardnog API-ja, misc.Unsafe::defineAnonymousClass, s namjerom da se ukine zbog uklanjanja u budućem izdanju. Također, jezik Java ne smije se mijenjati kao rezultat ovog prijedloga.
  • Z Zbirka smeća (ZGC) izdvaja eksperimentalnu značajku na proizvod prema ovom prijedlogu. Integriran u JDK 11, koji je stigao u rujnu 2018., ZGC je skalabilni sakupljač smeća s malim kašnjenjem. ZGC je predstavljen kao eksperimentalna sposobnost jer su programeri Jave odlučili da značajku ove veličine i složenosti treba uvoditi pažljivo i postupno. Od tada su dodana brojna poboljšanja, od istodobnog istovara klase, uklanjanja neiskorištene memorije i podrške za dijeljenje podataka klase do poboljšane NUMA svijesti i prethodnog dodirivanja hrpe s više niti. Također, povećana je maksimalna veličina hrpe s četiri terabajta na 16 terabajta. ZGC rješava probleme izvedbe u aplikacijama koje uključuju velike količine podataka, poput strojnog učenja,gdje korisnici žele biti sigurni da obrada podataka neće biti podložna nepredvidljivosti ili dugim pauzama zbog odvoza smeća. Podržane platforme uključuju Linux, Windows i MacOS.
  • Tekstualni blokovi, pregledani i u JDK 14 i u JDK 13, namijenjeni su pojednostavljenju zadatka pisanja Java programa olakšavajući izražavanje nizova koji se protežu u nekoliko redaka izvornog koda, istodobno izbjegavajući nizove izbjegavanja u uobičajenim slučajevima. Tekstualni blok je višeredni doslovni niz koji izbjegava potrebu za većinom izlaznih sekvenci, automatski oblikuje niz na predvidljiv način i nudi programeru kontrolu nad formatom po želji. Cilj prijedloga tekstualnih blokova je poboljšanje čitljivosti nizova u Java programima koji označavaju kod napisan na ne-Java jezicima. Sljedeći je cilj podržati migraciju iz literalnih nizova, navodeći da bilo koja nova konstrukcija može izraziti isti niz nizova kao literal niza, interpretirati iste izlazne sekvence i njime se manipulirati na isti način kao literalni niz.Programeri OpenJDK nadaju se da će dodati sekvence izlaska za upravljanje eksplicitnim razmakom i kontrolom novog reda.
  • Sakupljač smeća Shenandoah s malim stankama postat će proizvodna značajka i izići iz eksperimentalne faze. Prije godinu dana integriran je u JDK 12.
  • Uklanjanje Nashorna, koji je debitirao u JDK 8 u ožujku 2014., ali je od tada zastario tehnologijama poput GraalVM. Prijedlog OpenJDK 15 poziva na uklanjanje Nashorn API-ja i alata za naredbe jjs koji se koristi za pozivanje Nashorna.
  • Ukidanje RMI mehanizma za aktiviranje za buduće uklanjanje. Mehanizam RMI aktivacije zastarjeli je dio RMI-a koji nije obvezan od Jave 8. RMI aktivacija nameće trajni teret održavanja. Nijedan drugi dio RMI-a neće biti zastario.