Java Development Kit 15, implementace Oracle další verze Java SE (Standard Edition), bude k dispozici jako produkční verze dnes, 15. září 2020. Mezi hlavní přednosti JDK 15 patří textové bloky, skryté třídy, přístupové rozhraní cizí paměti, Z Garbage Collector a náhledy zapečetěných tříd, porovnávání vzorů a záznamů.
JDK 15 je jen krátkodobé vydání, které bude podporováno podporou Oracle Premier Support po dobu šesti měsíců, dokud JDK 16 nepřijde příští březen. JDK 17, další vydání dlouhodobé podpory, které bude společnost Oracle podporovat po dobu osmi let, má přijít o rok později, podle šestiměsíčního kadence vydání Oracle pro verze Java SE.
Vývojáři se nyní mohou podívat na JDK 15, aby získali představu o tom, co bude v JDK 17, uvedl Georges Saab, prezident skupiny Java Platform Group společnosti Oracle. Aktuální vydání LTS je JDK 11, které dorazilo v září 2018. Vydání LTS přicházejí každé tři roky. JDK 15 navazuje na JDK 14, který byl vydán 17. března 2020.
Nové funkce a změny v OpenJDK 15:
- Druhý inkubátor rozhraní API pro přístup do cizí paměti, které by umožňovalo programům Java bezpečný a efektivní přístup k cizí paměti mimo haldu Java. API by mělo být schopné pracovat na různých druzích cizí paměti, jako je nativní, perzistentní a spravovaná halda. Mnoho programů Java přistupuje k cizí paměti, například Ignite a MapDB. API by pomohlo vyhnout se nákladům a nepředvídatelnosti spojeným s uvolňováním paměti, sdílet paměť napříč procesy a serializovat a deserializovat obsah paměti mapováním souborů do paměti. Rozhraní Java API v současné době neposkytuje uspokojivé řešení pro přístup do cizí paměti. S novým návrhem by však nemělo být možné, aby API narušilo bezpečnost JVM. Tato funkce prochází dřívější inkubační fází v JDK 14, přičemž vylepšení jsou nabízena v JDK 15.
- Náhled zapečetěných tříd. Spolu s rozhraními uzavřené třídy omezují, které další třídy nebo rozhraní je mohou rozšířit nebo implementovat. Cíle této funkce zahrnují umožnit autorovi třídy nebo rozhraní řídit, který kód je zodpovědný za jeho implementaci, poskytnout deklarativnější způsob než modifikátory přístupu k omezení použití nadtřídy a podpořit budoucí směry v porovnávání vzorů podporou vyčerpávajícího analýza vzorů.
- Odebrání zdrojového kódu a podpora sestavení pro porty Solaris / SPARC, Solaris / x64 a Linux / SPARC, jejichž podpora v JDK 14 byla ukončena s úmyslem je v budoucím vydání odstranit. Mnoho projektů a funkcí ve vývoji, jako je Valhalla, Loom a Panama, vyžaduje významné změny architektury CPU a kódu specifického pro operační systém. Ukončení podpory portů Solaris a SPARC umožní přispěvatelům do komunity OpenJDK urychlit vývoj nových funkcí, které posunou platformu vpřed. Systémy Solaris i SPARC byly v posledních letech nahrazeny operačními systémy Linux a Intel.
- Záznamy, které jsou třídami, které fungují jako transparentní nosiče neměnných dat, by byly zahrnuty do druhé verze náhledu v JDK 15 po debutování jako časný náhled v JDK 14. Cíle plánu zahrnují vytvoření objektově orientovaného konstruktu, který vyjadřuje jednoduchá agregace hodnot, pomoc programátorům zaměřit se spíše na modelování neměnných dat než na rozšiřitelné chování, automatická implementace metod založených na datech, jako jsou rovní a hodnotitelé, a zachování dlouhodobých principů Java, jako je nominální typizace a kompatibilita migrace. Záznamy lze považovat za nominální n-tice.
- Kryptografické podpisy založené na algoritmu digitálního podpisu Edwardsovy křivky (EdDSA). EdDSA je moderní schéma eliptické křivky s výhodami oproti stávajícím schématům podpisů v JDK. EdDSA bude implementován pouze u poskytovatele SunEC. EdDSA je žádaný kvůli jeho lepšímu zabezpečení a výkonu ve srovnání s jinými podpisovými schématy; je již podporován v krypto knihovnách, jako je OpenSSL a BoringSSL.
- Reimplementace staršího rozhraní DatagramSocket API nahrazením podkladových implementací
java.net.datagram.Socketajava.net.MulticastSocketAPI s jednoduššími a modernějšími implementacemi, které 1. lze snadno ladit a udržovat, a 2. pracují s virtuálními vlákny, která jsou aktuálně zkoumána v Project Loom. Nový plán navazuje na JDK Enhancement Proposal 353, který znovu implementoval starší Socket API. Stávající implementacejava.net.datagram.Socketajava.net.MulticastSocketse datuje k JDK 1.0 a době, kdy byl IPv6 stále ve vývoji. Proto současná implementaceMulticastSocketse snaží sladit IPv4 a IPv6 způsoby, které se obtížně udržují. - Ve výchozím nastavení zakázání zaujatého uzamčení a ukončení všech souvisejících možností příkazového řádku. Cílem je určit potřebu pokračující podpory optimalizace synchronizovaného synchronizace nákladného na údržbu staršího synchronizace, která se ve virtuálním stroji HotSpot používá ke snížení režie nekontrolovaného uzamčení. Ačkoli některé aplikace Java mohou vidět regresi ve výkonu s deaktivovaným předpjatým zamykáním, zisky výkonu předpjatého zamykání jsou obecně méně patrné, než bývaly.
- Druhý náhled shody vzorů pro
instanceof, po předchozím náhledu v JDK 14. Porovnávání vzorů umožňuje snadnější a výstižnější vyjádření běžné logiky v programu, zejména podmíněné extrakce komponent z objektů. Jazyky jako Haskell a C # přijaly shodu vzorů pro svou stručnost a bezpečnost. - Skryté třídy, tj. Třídy, které nelze přímo použít v bajtkódu jiných tříd, jsou určeny pro použití rámci, které generují třídy za běhu a které je používají nepřímo prostřednictvím reflexe. Skrytou třídu lze definovat jako člena hnízda řízení přístupu a lze ji uvolnit nezávisle na jiných třídách. Návrh by zlepšil účinnost všech jazyků na JVM povolením standardního API definovat skryté třídy, které nejsou zjistitelné a mají omezený životní cyklus. Rámec uvnitř i vně JDK by byl schopen dynamicky generovat třídy, které by místo toho mohly definovat skryté třídy. Mnoho jazyků postavených na JVM spoléhá na dynamické generování tříd pro flexibilitu a efektivitu. Cíle tohoto návrhu zahrnují: umožnění rámcům definovat třídy jako nezjistitelné podrobnosti implementace rámce, takže je nelze spojit s jinými třídami ani objevit pomocí reflexe; podpora pro rozšíření hnízda řízení přístupu s neobjevitelnými třídami; a podpora agresivního vykládání neobjevitelných tříd, takže rámce mají flexibilitu definovat tolik, kolik je potřeba. Dalším cílem je zastarat nestandardní API,
misc.Unsafe :: defineAnonymousClasss úmyslem ukončit podporu v budoucím vydání. Výsledkem tohoto návrhu nebude ani změna jazyka Java. - Z Garbage Collector (ZGC) přechází z experimentální funkce na produkt podle tohoto návrhu. Integrovaný do JDK 11, který dorazil v září 2018, je ZGC škálovatelný sběrač odpadků s nízkou latencí. ZGC byl představen jako experimentální funkce, protože vývojáři Java rozhodli, že funkce této velikosti a složitosti by měla být zavedena opatrně a postupně. Od té doby byla přidána řada vylepšení, od souběžného vykládání tříd, zrušení závazků nevyužité paměti a podpory sdílení dat o třídách až po vylepšené povědomí o NUMA a předběžné dotyky s více vlákny. Také byla zvýšena maximální velikost haldy ze čtyř terabajtů na 16 terabajtů. ZGC řeší problémy s výkonem v aplikacích, které zahrnují obrovské množství dat, jako je strojové učení, kde si uživatelé chtějí být jisti, že zpracování dat nebude podléhat nepředvídatelnosti nebo dlouhým pauzám kvůli uvolňování paměti. Podporované platformy zahrnují Linux, Windows a MacOS.
- Účelem textových bloků, jejichž náhled je v JDK 14 i JDK 13, je zjednodušit psaní programů Java tím, že usnadní vyjádření řetězců zahrnujících několik řádků zdrojového kódu, přičemž se v běžných případech vyhne sekvenci úniku. Textový blok je víceřádkový řetězcový literál, který se vyhne potřebě většiny únikových sekvencí, automaticky formátuje řetězec předvídatelným způsobem a v případě potřeby nabízí vývojáři kontrolu nad formátem. Cílem návrhu textových bloků je zvýšit čitelnost řetězců v programech Java, které označují kód napsaný v jiných jazycích než Java. Dalším cílem je podpora migrace z řetězcových literálů stanovením, že jakýkoli nový konstrukt může vyjádřit stejnou sadu řetězců jako řetězcový literál, interpretovat stejné únikové sekvence a manipulovat stejným způsobem jako řetězcový literál. Vývojáři OpenJDK doufají, že přidají řídicí sekvence pro správu explicitního prázdného prostoru a ovládání nového řádku.
- Sběratel odpadků Shenandoah s nízkou pauzou by se stal produkčním prvkem a vystoupil z experimentální fáze. Byl integrován do JDK 12 před rokem.
- Odstranění Nashornu, který debutoval v JDK 8 v březnu 2014, ale od té doby ho zastaraly technologie jako GraalVM. Návrh OpenJDK 15 požaduje odstranění rozhraní Nashorn API a nástroje příkazového řádku jjs, který se používá k vyvolání Nashornu.
- Ukončení podpory aktivačního mechanismu RMI pro budoucí odstranění. Mechanismus aktivace RMI je zastaralá část RMI, která je volitelná od verze Java 8. Aktivace RMI představuje trvalou zátěž údržby. Podpora jiné části RMI nebude ukončena.
