JDK 15: Новите функции в Java 15

Java Development Kit 15, внедряването от Oracle на следващата версия на Java SE (Standard Edition), се предлага като производствена версия днес, 15 септември 2020 г. Акцентите на JDK 15 включват текстови блокове, скрити класове, API за достъп до чужда памет, Z Garbage Collector и визуализации на запечатани класове, съвпадение на шаблони и записи.

JDK 15 е само краткосрочна версия, само за да се поддържа с поддръжката на Oracle Premier в продължение на шест месеца, докато JDK 16 пристигне следващия март. JDK 17, следващото издание за дългосрочна поддръжка, което ще се поддържа от Oracle в продължение на осем години, трябва да пристигне след една година, според шестмесечния ритъм на Oracle за версии на SE SE.

Разработчиците могат да разгледат JDK 15 сега, за да получат представа какво ще бъде в JDK 17, каза Жорж Сааб, президент на Java Platform Group на Oracle. Настоящото LTS издание е JDK 11, което пристигна през септември 2018 г. LTS изданията пристигат на всеки три години. JDK 15 следва JDK 14, който беше пуснат на 17 март 2020 г. 

Новите функции и промени в OpenJDK 15:

  • Втори инкубатор на API за достъп до чужда памет, който ще позволи на Java програми безопасно и ефективно да осъществяват достъп до чужда памет извън Java купчината. API трябва да може да работи с различни видове чужда памет, като вродена, постоянна и управлявана купчина. Много Java програми имат достъп до чужда памет, като Ignite и MapDB. API би спомогнал за избягване на разходите и непредсказуемостта, свързани със събирането на боклука, споделяне на паметта между процесите и сериализиране и десериализиране на съдържанието на паметта чрез картографиране на файлове в паметта. Понастоящем Java API не предоставя задоволително решение за достъп до чужда памет. Но с новото предложение не би трябвало API да подкопава безопасността на JVM. Тази способност преминава през по-ранна фаза на инкубатор в JDK 14, с подобрения, предложени в JDK 15. 
  • Преглед на запечатани класове. Заедно с интерфейсите, запечатаните класове ограничават кои други класове или интерфейси могат да ги разширяват или изпълняват. Целите на тази функция включват позволяване на автора на клас или интерфейс да контролира кой код е отговорен за прилагането му, осигуряване на по-декларативен начин от модификаторите на достъпа за ограничаване на използването на суперклас и подкрепа на бъдещи указания за съвпадение на шаблони, като подкрепя изчерпателното анализ на модели.
  • Премахване на изходния код и поддръжка за изграждане на портове Solaris / SPARC, Solaris / x64 и Linux / SPARC, които бяха оттеглени за премахване в JDK 14 с намерението да ги премахнат в бъдеща версия. Много проекти и функции в разработка като Valhalla, Loom и Panama изискват значителни промени в архитектурата на процесора и специфичния за операционната система код. Премахването на поддръжката за портовете Solaris и SPARC ще даде възможност на участниците в общността OpenJDK да ускорят разработването на нови функции, които ще придвижат платформата напред. Както Solaris, така и SPARC бяха заменени през последните години от операционната система Linux и процесорите Intel.
  • Записите, които са класове, които действат като прозрачни носители на неизменяеми данни, ще бъдат включени във втора версия за предварителен преглед в JDK 15, след дебютиране като ранен преглед в JDK 14. Целите на плана включват разработване на обектно-ориентирана конструкция, която изразява просто агрегиране на стойности, което помага на програмистите да се съсредоточат върху моделиране на неизменяеми данни, а не на разширяемо поведение, автоматично прилагане на методи, управлявани от данни, като еквали и оценители, и запазване на дългогодишни принципи на Java като номинално типизиране и съвместимост на миграцията. Записите могат да се възприемат като номинални кортежи. 
  • Криптографски подписи, базирани на алгоритъма за цифров подпис на Edwards-Curve (EdDSA). EdDSA е модерна схема на елиптична крива с предимства пред съществуващите схеми за подпис в JDK. EdDSA ще бъде внедрен само в доставчика SunEC. EdDSA се търси поради подобрената си сигурност и производителност в сравнение с други схеми за подпис; той вече се поддържа в крипто библиотеки като OpenSSL и BoringSSL.
  • Повторно прилагане на наследения API на DatagramSocket чрез замяна на основните имплементации на  API java.net.datagram.Socketи java.net.MulticastSocketAPI с по-прости и модерни имплементации, които 1. са лесни за отстраняване на грешки и поддръжка и 2. работят с виртуални нишки, които в момента се изследват в Project Loom. Новият план е продължение на предложението за подобрение на JDK 353, което е въвело отново наследения API на Socket. Текущите имплементации java.net.datagram.Socketи java.net.MulticastSocketдатират от JDK 1.0 и от времето, когато IPv6 все още е в процес на разработка. По този начин текущото изпълнение се  MulticastSocket опитва да съгласува IPv4 и IPv6 по начини, които са трудни за поддържане.
  • Деактивиране на предубеденото заключване по подразбиране и отхвърляне на всички свързани опции на командния ред. Целта е да се определи необходимостта от непрекъсната поддръжка на скъпата за поддържане наследствена оптимизация на синхронизацията на пристрастното заключване, която се използва във виртуалната машина HotSpot за намаляване на режийните разходи за неограничено заключване. Въпреки че някои Java приложения могат да видят регресия в производителността с деактивирано блокиране на предубедеността, подобренията в производителността на предубеденото заключване обикновено са по-малко очевидни, отколкото преди.
  • Втори предварителен преглед на съвпадение на шаблони за instanceof, след предходен предварителен преглед в JDK 14. Съпоставянето на образци позволява общата логика в програмата, главно условното извличане на компоненти от обекти, да бъде изразена по-лесно и кратко. Езици като Haskell и C # са възприели съвпадение на моделите за неговата краткост и безопасност.
  • Скритите класове, т.е. класове, които не могат да се използват директно от байт кода на други класове, са предназначени за използване от рамки, които генерират класове по време на изпълнение и които ги използват косвено чрез отражение. Скритият клас може да бъде дефиниран като член на гнездото за контрол на достъпа и може да бъде разтоварен независимо от другите класове. Предложението ще подобри ефективността на всички езици в JVM, като даде възможност на стандартен API да дефинира скрити класове, които не се откриват и имат ограничен жизнен цикъл. Рамките вътре и извън JDK ще могат да генерират динамично класове, които вместо това могат да дефинират скрити класове. Много езици, изградени върху JVM, разчитат на динамично генериране на клас за гъвкавост и ефективност. Целите на това предложение включват: позволяване на рамки да определят класовете като неоткриваеми подробности за изпълнението на рамката,така че те не могат да бъдат свързани срещу други класове, нито да бъдат открити чрез размисъл; поддръжка за разширяване на гнездо за контрол на достъпа с неоткриваеми класове; и поддръжка за агресивно разтоварване на неоткриваеми класове, така че рамките имат гъвкавостта да определят толкова, колкото е необходимо. Друга цел е да отхвърли нестандартния API, misc.Unsafe::defineAnonymousClass, с намерението да бъде оттеглено за премахване в бъдещо издание. Освен това езикът Java не трябва да се променя в резултат на това предложение.
  • Z Garbage Collector (ZGC) завършва експериментална функция за продукт по това предложение. Интегриран в JDK 11, който пристигна през септември 2018 г., ZGC е мащабируем колектор за боклук с ниска латентност. ZGC беше представен като експериментална възможност, тъй като разработчиците на Java решиха, че характеристика с този размер и сложност трябва да се въвежда внимателно и постепенно. Оттогава бяха добавени редица подобрения, вариращи от едновременно разтоварване на класа, освобождаване на неизползваната памет и поддръжка за споделяне на данни от клас до подобрена информираност за NUMA и предварително докосване на купчина с много нишки. Също така, максималният размер на купчината е увеличен от четири терабайта на 16 терабайта. ZGC разглежда проблемите с производителността в приложения, които включват огромни количества данни, като машинно обучение,където потребителите искат да бъдат сигурни, че обработката на данни няма да бъде обект на непредсказуемост или дълги паузи поради събирането на боклука. Поддържаните платформи включват Linux, Windows и MacOS.
  • Текстовите блокове, визуализирани както в JDK 14, така и в JDK 13, имат за цел да опростят задачата за писане на Java програми, като улесняват изразяването на низове, които обхващат няколко реда изходен код, като същевременно избягват последователностите на бягство в често срещани случаи. Текстовият блок е многоредов литералов низ, който избягва необходимостта от повечето последователности за бягство, автоматично форматира низа по предсказуем начин и предлага на разработчика контрол върху формата, когато желаете. Целта на предложението за текстови блокове е подобряване на четливостта на низовете в Java програми, които обозначават код, написан на езици, които не са Java. Друга цел е да се поддържа миграция от низ литерали, като се предвижда, че всяка нова конструкция може да изразява същия набор от низове като низ литерал, да интерпретира същите изходни последователности и да бъде манипулирана по същия начин като низ литерал.Разработчиците на OpenJDK се надяват да добавят изходни последователности, за да управляват изрично празно пространство и контрол на нов ред.
  • Събирачът на боклук с ниска пауза Shenandoah ще се превърне в производствена функция и ще излезе от експерименталния етап. Преди година беше интегриран в JDK 12.
  • Премахване на Nashorn, който дебютира в JDK 8 през март 2014 г., но оттогава е остарял от технологии като GraalVM. Предложението OpenJDK 15 призовава за премахване на API на Nashorn и инструмента за команден ред jjs, използван за извикване на Nashorn.
  • Оттегляне на механизма за активиране на RMI за бъдещо премахване. Механизмът за активиране на RMI е остаряла част от RMI, която не е задължителна от Java 8. Активирането на RMI налага непрекъсната тежест за поддръжка. Никоя друга част от RMI няма да бъде остаряла.