Выпуск Java SE 16

Пасля шасці месяцаў распрацоўкі кампанія Oracle выпусціла платформу Java SE 16 (Java Platform, Standard Edition 16), у якасці эталоннай рэалізацыі якой выкарыстоўваецца адчынены праект OpenJDK. У Java SE 16 захавана зваротная сумяшчальнасць з мінулымі выпускамі платформы Java, усё раней напісаныя Java-праекты без змен будуць працаздольныя пры запуску пад кіраваннем новай версіі. Гатовыя для ўсталёўкі зборкі Java SE 16 (JDK, JRE і Server JRE) падрыхтаваны для Linux (x86_64, AArch64), Windows і macOS. Распрацаваная ў рамках праекту OpenJDK эталонная рэалізацыя Java 16 цалкам адчыненая пад ліцэнзіяй GPLv2 з выключэннямі GNU ClassPath, якія дазваляюць дынамічнае звязванне з камерцыйнымі прадуктамі.

Java SE 16 аднесены да катэгорыі выпускаў са звычайным тэрмінам падтрымкі, абнаўленні для якога будуць выпускацца да наступнага рэлізу. У якасці галінкі з працяглым тэрмінам падтрымкі (LTS) варта выкарыстоўваць Java SE 11, абнаўленні для якога будуць выпускацца да 2026 гады. Наступны LTS-рэліз намечаны на верасень 2021 года. Нагадаем, што пачынальна з выпуску Java 10 праект перайшоў на новы працэс распрацоўкі, які разумее карацейшы цыкл фармавання новых рэлізаў. Новая функцыянальнасць зараз развіваецца ў адной стала якая абнаўляецца master-галінцы, у якую ўключаюцца ўжо гатовыя змены і ад якой раз у шэсць месяцаў адгаліноўваюцца галінкі для стабілізацыі новых выпускаў.

Пры падрыхтоўцы новага выпуску распрацоўка пераведзена з сістэмы кіравання версіямі Mercurial на Git і платформу сумеснай распрацоўкі GitHub. Чакаецца, што міграцыя дазволіць павысіць прадукцыйнасць аперацый з рэпазітаром, павялічыць эфектыўнасць захоўвання, забяспечыць доступ да змен за ўсю гісторыю праекта, палепшыць падтрымку рэцэнзавання кода і задзейнічаць API для аўтаматызацыі працоўных працэсаў. Акрамя таго, ужыванне Git і GitHub робіць праект больш прывабным для пачаткоўцаў і распрацоўнікаў, якія звыкнуліся да Git.

З навін Java 16 можна адзначыць:

  • Дададзены эксперыментальны модуль jdk.incubator.vector з рэалізацыяй API Vector, які прадстаўляе функцыі для вектарных вылічэнняў, якія выконваюцца з выкарыстаннем вектарных інструкцый працэсараў x86_64 і AArch64 і дазваляюць адначасова прымяніць аперацыі адразу да некалькіх значэнняў (SIMD). У адрозненне ад якія прадстаўляюцца ў JIT-кампілятары HotSpot магчымасцяў па аўтавектарызацыі скалярных аперацый, новы API дазваляе відавочна кіраваць вектарызацыі для раўналежнай апрацоўкі дадзеных.
  • У кодзе JDK і VM HotSpot, напісаным на C++, дазволена выкарыстоўваць магчымасці, якія з'явіліся ў спецыфікацыі C++14. Раней дапушчалася выкарыстанне стандартаў C++98/03.
  • У зборшчык смецця ZGC (Z Garbage Collector), які працуе ў пасіўным рэжыме і наколькі гэта магчыма мінімізуе затрымкі з-за зборкі смецця, дададзена магчымасць раўналежнай апрацоўкі стэкаў струменяў без прыпынення выканання струменяў прыкладання. У ZGC зараз засталіся толькі патрабавальныя прыпыненні працы, якія маюць сталыя затрымкі, звычайна не якія перавышаюць некалькіх сотняў мікрасекунд.
  • У класах SocketChannel, ServerSocketChannel і java.nio.channels дададзена падтрымка Unix-сокетаў (AF_UNIX).
  • Рэалізаваны порт для Linux-дыстрыбутыва Alpine cа стандартнай Сі-бібліятэкай musl, які папулярны ў асяроддзі для кантэйнераў, мікрасэрвісаў, хмарных і ўбудаваных сістэм. Прапанаваны порт у падобных асяродках дазваляе выконваць праграмы на Java як звычайныя прыкладанні. Акрамя таго, пры дапамозе jlink можна прыбраць усе невыкарыстоўваныя модулі і сфармаваць мінімальнае асяроддзе, дастатковае для выканання прыкладання, што дазваляе ствараць спецыфічныя для пэўных прыкладанняў кампактныя выявы.
  • Рэалізаваны механізм Elastic Metaspace, які аптымізуе аперацыі вылучэння і вяртанні памяці, займанай метададзенымі класаў (metaspace) у JVM HotSpot. Ужыванне Elastic Metaspace змяншае фрагментацыю памяці, памяншае накладныя выдаткі ў загрузніку класаў, а таксама дабратворна ўплывае на прадукцыйнасць доўга выкананых серверных прыкладанняў за кошт хутчэйшага звароту аперацыйнай сістэме памяці, займанай невыкарыстоўванымі метададзенымі класаў. Для выбару рэжыму вызвалення памяці пасля выгрузкі класаў прапанавана опцыя "-XX: MetaspaceReclaimPolicy = (balanced | aggressive | none)".
  • Дададзены порт JDK для сістэм Windows, якія працуюць на абсталяванні з працэсарамі на базе архітэктуры AArch64.
  • Прапанаваны трэці папярэдні варыянт API Foreign-Memory Access, які дазваляе Java-прыкладанням бяспечна і эфектыўна атрымаць доступ да абласцей памяці, па-за кучай Java, маніпулюючы новымі абстракцыямі MemorySegment, MemoryAddress і MemoryLayout.
  • Рэалізаваны эксперыментальны API Foreign Linker, які прадстаўляе доступ з Java да натыўнага коду. Разам з API Foreign-Memory новы праграмны інтэрфейс прыкметна спрашчае стварэнне абвязак над звычайнымі падзялянымі бібліятэкамі.
  • Дададзена ўтыліта jpackage, якая дазваляе ствараць пакеты для самадастатковых (self-contained) Java-прыкладанняў. Утыліта грунтуецца на javapackager з JavaFX і дазваляе фармаваць пакеты ў фарматах, родных для розных платформаў (msi і exe для Windows, pkg і dmg для macOS, deb і rpm для Linux). Пакеты ўключаюць усе неабходныя залежнасці.
  • Уключаная па змаўчанні строгая інкапсуляцыя ўсіх унутраных элементаў JDK, за выключэннем крытычных API, такіх як sun.misc.Unsafe. Значэнне опцыі "-illegal-access" зараз па змаўчанні выстаўлена ў "deny" замест "permit", што прывядзе да блакавання спроб звароту з кода да большасці ўнутраных класаў, метадаў і палёў. Для абыходу абмежавання варта выкарыстоўваць опцыю "-illegal-access=permit".
  • Стабілізаваная рэалізацыя супастаўлення з узорам у аператары "instanceof", якая дазваляе адразу вызначыць лакальную зменную для звароту да праверанага значэння. Напрыклад, можна адразу пісаць "if (obj instanceof String s&& s.length() > 5) {.. s.contains(..) ..}" без відавочнага азначэння "String s = (String) obj". Было: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Цяпер можна абысціся без вызначэння "Group group = (Group) obj": if (obj instanceof Group group) { var entries = group.getEntries(); }
  • Стабілізаваная рэалізацыя ключавога слова «record», які прадстаўляе кампактную форму для вызначэння класаў, якая дазваляе абыйсціся без відавочнага вызначэння розных нізкаўзроўневых метадаў, такіх як equals(), hashCode() і toString(), у выпадках, калі дадзеныя захоўваюцца толькі ў палях, паводзіны працы з якімі не мяняецца. Калі ў класе выкарыстоўваюцца тыпавыя рэалізацыі метадаў equals(), hashCode() і toString(), у ім можна абыйсціся без іх відавочнага азначэння: public record BankTransaction

    Дадзеная аб'ява прывядзе да аўтаматычнага дадання рэалізацый метадаў equals(), hashCode() і toString() у дадатак да канструктара і метадам, якія кантралююць змену дадзеных (getter).

  • Прапанаваны другі папярэдні варыянт запячатаных ("sealed") класаў і інтэрфейсаў, якія не могуць выкарыстоўвацца іншымі класамі і інтэрфейсамі для атрымання ў спадчыну, пашырэнні або перавызначэння рэалізацыі. Запячатаныя класы таксама падаюць больш дэкларатыўны спосаб абмежавання выкарыстання суперкласа, чым мадыфікатары доступу, заснаваны на відавочным пераліку падкласаў, дазволеных для пашырэння. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}

Крыніца: opennet.ru

Дадаць каментар