какая последняя версия джава 2021
What can we do with Java16? Краткий обзор нового релиза JDK (март 2021)
JDK 16. Чего нам ждать от Java в марте?
В марте разработчикам в их привычных средах разработки пришло сообщение “New JDK version is available”, что означало, что вышел очередной релиз Java 16 с открытым исходным кодом Java SE (Standard Edition) 16 и Java Development Kit 16 (JDK 16). Подготовка к выпуску окончена, и набор новых функций (JEP), который был утвержден, теперь реализован в JDK и опубликован в открытом доступе. Известно, что для 16-го релиза новых JEP уже не будет. А следующий, 17-й релиз выйдет в сентябре. Ах да, что же такое JEP для новых релизов Java? Для новичка это всегда не очень понятно.
Что такое JEP в превью к JDK.
Мы предлагаем разработчикам, аналитикам, архитекторам и просто любителям Java наш краткий и далеко не самый полный обзор, чтобы получить представление о том, что поменяется в JDK 16.
Что изменилось в общем?
Некоторые из предстоящих основных функций JDK 16 включают одновременную обработку стека потоков для «сборки мусора», поддержку функций языка C++ 14, возможность гибкого (elastic) Metaspace для более быстрого возврата неиспользуемой памяти в операционную систему, изменения в организации процедур, новые API и инструменты, порты операционной системы, инкапсулирование начинки JDK и некоторые другие вещи.
Нам бы хотелось отметить следующие знаковые вещи:
Итак, игнорировать роль старых добрых Fortran и C++ перестали. Действительно, когда требуется скорость вычислений, JAVA не справится и пора это признать.
Git чрезвычайно удобная вещь, незаменимая в современном процессе разработки. Разработчик JDK 16 посвятил GIT несколько JEP.
Внешняя память, сборка муссора и кэш. Традиционно важные пункты для каждого нового релиза JAVA. Роль проектов на микросервисной архитектуре тредует нововведений.
Где-то хорош Linux и взаимодействие JAVA с ним бесспорно надо развивать, но в последнее время Windows также развивается и появляются серверные технологии на ее основе. Начиная с этого релиза произвоится попытка дать разработчикам, ведущим работу в разных операционных системах удобные инструменты.
JEP 397: Изолированные классы (sealed classes) становятся еще более изолированными:
Об изоляции классов речь шла ранее в JDK 15. Именно в рамках 15-го релиза были предложены и поставлены изолированные классы (sealed classes) в качестве preview feature. Напомним, что концепция изолированных классов предусматривает ограничение возможности их расширения или выполнения для других классов. Фактически это означает запрет наследоваться от данного (изолированного) класса.
Разрешить разработчику класса или интерфейса самому контролировать, какая часть кода будет отвечать за его реализацию
Предоставить более удобный и понятный способ, чем модификаторы доступа (access modifiers), для ограничения использования суперклассов.
Поддержать дальнейшее развитие “паттерн матчинга” (pattern Matching), предоставив фундамент для полного анализа паттернов.
Что это означает и к чему приведет?
В JLS придется описывать контекстные ключевые слова (contextual keyword), которые заменят введенные ранее идентификаторы и ключевые слова типа (estricted keyword и restricted identifier). Для этого следует вводить набор изолированных и неизолированных последовательностей символов и разрешить их применять в качестве контекстуальных ключевых слов в среде разработки. Также, нужно быть готовым к тому, что компилятор будет проводить более строгую проверку при конверсии типов, в иерархии которых есть изолированные классы или интерфейсы.
JEP 396: Инкапсуляция внутри JDK теперь стала строгой:
Для чего:
Повысить безопасность и ремонтопригодность JDK, как части Project Jigsaw, и призвать разработчиков перейти от использования внутренних элементов JDK к стандартным API.Делается это для того чтобы возмоно было легко перейти к использованию дальнейших версий Java.
Этот JEP несет в себе риск того, что существующий код Java не будет запущен. Разработчикам рекомендуется использовать инструмент jdeps для идентификации кода, который опирается на внутренние элементы JDK, и при наличии переключаться на их стандартные замены.
Что изменилось:
2. Если код требует доступа к внутренностям JDK во время выполнения, то, чтобы он отработал на Java 16, ему теперь придется явно указывать одну из трех опций JVM:
–illegal-access=permit/warn/debug: открытие всех пакетов JDK
–add-opens=module/package=target-module: открытие одного пакета
–add-exports=module/package=target-module: экспортирование одного пакета (только для статического доступа).
EP 395: Записи:
Записи были ранее введены в ответ на критику о том, что Java стала слишком громоздкой из-за большого количества формальных шаблонов или паттернов. О записях шла речь и ранее. Предварительно они были представлены в JDK 14 и JDK 15. Теперь можно свободно расширять язык программирования Java с помощью записей, которые являются классами, выполняющими функции прозрачных носителей неизменяемых данных. Записи можно рассматривать как именные кортежи.
Для чего:
Помочь разработчикам сосредоточиться на моделировании неизменяемых данных, а не на расширении вариаций их поведения.
Автоматически внедрять методы, управляемые данными, такие как equals и accessors.
Защитить первоначальные принципы Java, такие как номинальная типизация и совместимость с миграцией.
Что изменилось:
Так как какого-то более-менее внятного описания разработчик JDK никогда не предоставляет, нами опытным путем было установлено, что в Java 16 было внесено следующее изменение: теперь во внутренних классах разрешено объявлять статические члены.
JEP 394: Возможность сопоставления паттернов для экземпляра:
Данный JEP означает введение паттерна для оператора instanceof. Идея эта окончательно завершена в JDK 16, хотя ранее предварительно рассматривалась в релизах JDK 14 и JDK 15.
Для чего:
Популярная и часто используемая логика в программировании, такая как извлечение по условию компонентов из объектов, может быть выражена более сжато и безопасно с помощью сопоставления образцов, описанных в паттернах.
Что изменилось:
Фактически это означает введение паттерна для оператора instanceof.
JEP 393: API доступа к Foreign Memory (третий инкубатор):
API доступа к Foreign Memory, который ранее инкубировался как в JDK 14, так и в JDK 15, будет повторно инкубироваться в JDK 16 со значительными улучшениями. При этом функции интерфейсов MemureSegment и MemureAddresses стали различаться более четко.
Многие Java-программы получают доступ к «зарубежной памяти» Foreign Memory, например, Ignite, mapDB, memcached, Lucene и API ByteBuf от Netty. К сожалению, Java API на данный момент не обеспечивал удовлетворительного решения для доступа к Foreign Memory.
Для чего:
Для оптимизации расходов и ухода от непредсказуемости «сбора мусора». Особенно это касается тех случаев, когда у вас в проекте много обращений к кэшированным данным.
Теперь несколько процессов могут одновременно использовать память.
Сериализация и десериализация содержимого памяти путем преобразования файлов в память (например, через mmap).
Что изменилось
Фактически это означает введение паттерна для оператора instanceof. Идея эта завершена в JDK 16, хотя ранее была предварительно рассмотрена в JDK 14 и JDK 15.
JEP 392: Упаковочный инструмент теперь стал постоянным модулем:
Jpackage был реализован ранее в качестве инкубационного инструмента в JDK 14, таковым он оставался и в JDK 15. С JDK 16 jpackage получает права постоянного модуля.
Инструмент jpackage нужен для упаковки автономных средств Java. Многие Java-программы теперь получат доступ к foreign memory, например, Ignite, mapDB, memcached, Lucene и API ByteBuf от Netty. К сожалению, Java API так и не обеспечивает удовлетворительного решения для доступа к Foreign Memory.
Для чего:
Позволить указывать параметры времени запуска во время упаковки.
Разрешить использовать API-интерфейс ToolProvider для непосредственного вызова из командной строки.
Что изменилось:
jpackage получает права постоянного модуля
JEP 390: Warning для value-based классов:
Ситуация: объявите классы-оболочки примитивных типов (integer, double и прочее), а затем удалите их конструкторы. Что произойдет? Вы увидите, что в JAVA 16 это приведет к новым предупреждениям, о попытке неправильной синхронизации экземпляров классов на основе значений платформы Java.
JEP 389: Foreign Linker API:
Произведена попытка создать внешний API компоновщик, который обеспечивал бы статический, доступ через Java к коду, написанному на каком-то другом языке.
Этот API будет находиться на стадии инкубатора в JDK 16. Вместе с предлагаемым API доступа к Foreign Memoryчерез API внешнего компоновщика значительно упрощается методика связывания с собственными библиотеками, а также выбросом собственных ошибок.
Цель:
Обеспечить простоту в использовании java. Теперь можно заменить JNI новой моделью разработки на языке чистой Java.
Обеспечить поддержку языка C : первоначальный объем данного проекта направлен на то, чтобы предусмотреть высококачественную, полностью интегрированную совместимость с библиотеками C на платформах x64 и AArch64.
API Foreign Linker и его реализация должны быть достаточно универсальными для размещения в дальнейшем на других платформах различной разрядности (например, 32-разрядных x86) и прочих “внешних” функций, написанных на языках, отличных от C (например, C++, Fortran).
Обеспечить эффективность: International Linker API должен обеспечивать производительность, сравнимую или лучшую, чем JNI.
JEP 347: Включение языковых функций C++ 14
Теперь можно включать использование функций языка C++ 14 в исходном коде JDK. Не только включать, но и предоставить четкие инструкции по использованию этих функций в коде HotSpot.
Для чего:
Думаю, тут и так все ясно. Возможности C++14 уникальны для многих задач.
JEP 357: Миграция из Mercurial в Git:
Для чего:
Ожидаются преимущества в размере и доступных ресурсах через хостинг системы управления версиями.
JEP 369: Миграция на GitHub:
Предлагается репозиторий Host Git для сообщества OpenJDK на GitHub.
Для чего:
Чтобы можно было перемещать все проекты OpenJDK с одним исходным кодом на GitHub вместе с JEP 357 (Migrate from Mercurial to Git) и включить все версии JAVA 11 и более поздние обновления JDK, а также их более поздние модернизации.
JEP 376: ZGC: параллельная обработка стека потоков:
Переход потокового стека ZGC от safepoints к “параллельной” фазе.
Z Garbage Collector (ZGC) предназначен для того, чтобы оставить все проблемы с масштабируемостью в HotSpot при сборке мусора ушедшими в прошлое. На сегодняшний день операции GC, масштабирующие размер JAVA кучи и размер метапространства, были перенесены из операций с safepoints в “параллельные” фазы.
Это включило в себя: маркировку, перемещение, обработку ссылок, а также класс разгрузки и обработку большинства корней. Единственными операциями, все еще выполняемыми в safepoints GC, являются операции с подмножествами обработки “корня” и операции маркировки окончания с привязкой по времени.
Для чего:
Удалить обработку стека потоков из safepoints ZGC.
Сделать обработку стека удобной и упорядоченной.
Удалить всю лишнюю корневую обработку для каждого потока из safepoints ZGC.
JEP 386: Alpine Linux Port:
Порт JDK к архитектурам x64 и AArch64 в Alpine Linux и других дистрибутивах Linux, использующих библиотеку musl.
Из-за небольшого размера образа Alpine Linux широко используется в облачных развертываниях, в микросервисных системах и средах на основе контейнеров. Размер образа Docker для Linux меньше 6 МБ. В таких средах использование Java в нестандартных средах позволит Tomcat, Jetty, Spring и другим популярным фремворкам эффективнее работать в этих средах.
JEP 387: Elastic Metaspace
Ранее при использовании Metaspace возникали проблемы с высоким уровнем задействованной памяти вне JAVA кучи. Предложение включает схему распределения на основе Buddy для замены текущего распределителя памяти и включает алгоритм разделения памяти на разделы для удовлетворения запросов памяти.
Что изменилось:
Для того чтобы полностью использовать гибкость, обеспечиваемую Buddy Allocation, память Metaspace будет скомпонована в кластеры одинакового размера, которые могут использоваться независимо друг от друга.
JEP 388: Windows/AArch64 Порт
Теперь можно подключать JDK к платформе Windows/ AArch64.
Windows/ AArch64 стала, как платформа. играть более значительную роль с появлением нового серверного оборудования на основе AArch64 (ARM64). Основной целью этого JEP является включение порта в основное хранилище JDK, хотя само портирование остается в основном полным.
Руководство по возможностям Java версий 8-16
Вы можете использовать это руководство, чтобы получить практическую информацию о том, как найти и установить последнюю версию Java, понять различия между дистрибутивами Java (AdoptOpenJdk, OpenJDK, OracleJDK и т. д.), а также получить обзор функций языка Java, включая версии 8-16.
Вашему вниманию предлагается обновленная версия руководства от 05 апреля 2021 г.
Практическая информация
Во-первых, давайте рассмотрим некоторые общие практические вопросы, которые возникают у людей, пытающихся выбрать правильную версию Java для своего проекта.
TL; DR Мне нужна только ссылка для скачивания, и я знаю обо всем остальном. Куда мне следует идти?
Перейдите на сайт AdoptOpenJDK, выберите последнюю версию Java, загрузите и установите ее. Затем вернитесь к этому руководству, чтобы, возможно, еще кое-что узнать о версиях Java.
TL;DR (англ. too long; didn’t read — слишком длинно, не читал)
Какая последняя версия Java?
По состоянию на март 2021 года Java 16 является последней выпущенной версией Java.
Какую версию Java мне следует использовать?
Поскольку выходит так много новых версий, существуют в действительности имеются следующие сценарии использования:
Унаследованные проекты в компаниях часто застревают на Java 8 (см. раздел «Почему компании все еще застревают на Java 8?» ниже). Следовательно, вы также будете вынуждены использовать Java 8.
Если вы убедитесь, что используете самые последние IDE, фреймворки и инструменты сборки и начинаете новый проект, вы можете без колебаний использовать Java 11 (LTS) или даже последнюю версию Java 16.
Есть специальная область разработки Android, где версия Java в основном застряла на Java 7 с с доступом к определенному набору функций Java 8. Но вы можете переключиться на использование языка программирования Kotlin.
Почему компании все еще застряли на Java 8?
Есть несколько причин, по которым компании все еще придерживаются Java 8. Вот некоторые из них:
Инструменты сборки (Maven, Gradle и т. д.) и некоторые библиотеки изначально содержали ошибки с версиями Java > 8 и нуждались в обновлениях. Даже сегодня, например, с Java9+, некоторые инструменты сборки выводят предупреждения «reflective access» при сборке проектов Java, которые просто «кажутся не готовыми», даже если сборки в порядке.
Некоторые компании придерживаются политики использования только LTS-версий и полагаются на поставщиков своих ОС, которые предоставят им эти сборки, что требует времени.
Подводя итог: у вас есть сочетание практических вопросов (обновление ваших инструментов, библиотек, фреймворков) и политических проблем.
Почему некоторые версии Java, например 8, также называются 1.8?
Это просто означает Java 8. С переходом к основанным на времени выпускам с Java 9 схема именования также изменилась, и версии Java больше не имеют префикса 1.x. Теперь номер версии выглядит так:
В чем разница между версиями Java?
Должен ли я изучать конкретную?
Придя из других языков программирования с большими перерывами между выпусками, как, например, Python 2–3, вы можете спросить, применимо ли то же самое к Java.
Очевидно, что это не работает наоборот, скажем, ваша программа полагается на функции Java 14, которые просто недоступны в JVM Java 8.
Это означает несколько вещей:
Вы не просто «изучаете» конкретную версию Java, например 12.
Скорее, вы получите хорошую основу для всех языковых функций вплоть до Java 8. Это послужит хорошей базой.
И затем, из этого руководства вы можете узнать, какие дополнительные функции появились в Java 9-16, чтобы использовать их всегда, когда это возможно.
Каковы примеры этих новых возможностей новых версий Java?
Взгляните на раздел «Возможности Java 8-16» ниже.
Но, как правило: старые, более длинные циклы выпуска (3-5 лет, вплоть до Java 8) означали множество новых функций в каждом выпуске.
Шестимесячный цикл выпуска означает меньшее количество функций на выпуск, поэтому вы можете быстро освоить языковые функции Java 9-16.
В чем разница между JRE и JDK?
До сих пор мы говорили только о Java. Но что именно означает «Java»?
Во-первых, вам нужно провести различие между JRE (Java Runtime Environment) и JDK (Java Development Kit).
Исторически, вы загружали только JRE, если вас интересовали только программы Java. JRE включает, помимо прочего, виртуальную машину Java (JVM) и инструмент командной строки «java».
Для разработки новых программ на Java вам нужно было загрузить JDK. JDK включает в себя все, что есть в JRE, а также компилятор javac и несколько других инструментов, таких как javadoc (генератор документации Java) и jdb (отладчик Java).
Теперь, почему я говорю в прошедшем времени?
Вплоть до Java 8 веб-сайт Oracle предлагал JRE и JDK в качестве отдельных загрузок, хотя JDK также всегда включал JRE в отдельной папке. В Java 9 это различие практически исчезло, и вы всегда загружаете JDK. Структура каталогов JDK также изменилась, так как в ней больше не было явной папки JRE.
Таким образом, хотя некоторые дистрибутивы (см. Раздел «Дистрибутивы Java») по-прежнему предлагают отдельную загрузку JRE, похоже, существует тенденция предлагать только JDK. Следовательно, теперь мы будем использовать Java и JDK взаимозаменяемо.
Как мне установить Java или JDK?
Поэтому все, что вам нужно сделать, чтобы установить Java на свой компьютер, — это разархивировать файл jdk-<5-16>.zip. Вам даже не нужны права администратора для этого.
Ваш распакованный файл Java будет выглядеть так:
Магия происходит в каталоге /bin, который в Windows выглядит следующим образом:
Поэтому все, что вам нужно сделать, это разархивировать этот файл и поместить каталог /bin в переменную PATH, чтобы вы могли вызывать команду java из любого места.
В случае, если вам интересно, установщики с графическим интерфейсом, такие как Oracle или AdoptOpenJDK, выполняет распаковку и изменение переменной PATH вместо вас.
Дистрибутивы Java
Есть множество сайтов, предлагающих загрузки Java (читай: JDK), и неясно, «кто что предлагает и с какими лицензиями». Этот раздел прольет на это некоторый свет.
Проект OpenJDK
Что касается исходного кода Java (читайте: исходный код для вашего JRE / JDK), существует только один, живущий на сайте проекта OpenJDK.
Вот почему на практике есть несколько поставщиков, которые фактически создают эти сборки, сертифицируют (см. TCK) и затем распространяют их.
И хотя поставщики не могут, скажем, удалить метод из класса String перед созданием новой сборки Java, они могут добавить брэндинг (вay!) или добавить некоторые другие утилиты (например, CLI), которые они считают полезными. Но в остальном исходный код одинаков для всех дистрибутивов Java.
Сборки OpenJDK (от Oracle) и OracleJDK
Один из поставщиков, который создает Java из исходного кода, — это Oracle. Это приводит к двум разным дистрибутивам Java, что поначалу может казаться очень запутанными.
Сборки OpenJDK от Oracle (!). Эти сборки бесплатны и не имеют торговой марки, но Oracle не выпустит обновления для более старых версий, скажем, Java 15, как только выйдет Java 16.
OracleJDK — это коммерческая сборка под брендом, выпускаемая начиная с изменения лицензии в 2019 году. Это означает, что ее можно использовать бесплатно во время разработки, но вы должны платить Oracle, если используете ее в рабочей среде. При этом вы получаете более длительную поддержку, то есть все обновления дистрибутива и номер телефона, по которому можно позвонить, если с вашей JVM будут проблемы.
Исторически (до Java 8) существовали реальные исходные различия между сборками OpenJDK и сборками OracleJDK, при этом можно было сказать, что OracleJDK был «лучше». Но на сегодняшний день обе версии практически одинаковы, с небольшими отличиями.
Впрочем все сводится к тому, требуется ли вам коммерческая поддержка (номер телефона) для используемой версии Java.
AdoptOpenJDK
В 2017 году группа участников, разработчиков и поставщиков Java User Group (Amazon, Microsoft, Pivotal, Red Hat и другие) создала сообщество под названием AdoptOpenJDK.
Они предоставляют бесплатные надежные сборки OpenJDK с более длительной доступностью / обновлениями и даже предлагают вам выбор из двух разных виртуальных машин Java: HotSpot и OpenJ9.
Я очень рекомендую ее, если вы хотите установить Java.
Azul Zulu, Amazon Corretto, SAPMachine
Полный список сборок OpenJDK вы найдете на сайте OpenJDK Wikipedia. Среди них Azul Zulu, Amazon Corretto, а также SapMachine и многие другие. Упрощенно говоря, различия сводятся к тому, что у вас есть различные варианты поддержки/ гарантии обслуживания.
Но не забудьте проверить на сайтах дистрибьюторов, чтобы узнать о преимуществах каждого отдельного дистрибутива.
Полный обзор дистрибутива OpenJDK
Рафаэль Винтерхальтер (Rafael Winterhalter) собрал большой список всех доступных сборок OpenJDK, включая их описания: ОС, архитектуру, окна лицензирования, поддержки и обслуживания.
Рекомендация
Повторим с еще раз, что с 2020 года, если у вас нет особых требований, найдите файл jdk.zip (.tar.gz/.msi/.pkg) по адресу https://adoptopenjdk.net или выберите пакет, предоставленный вашим поставщиком ОС.
Возможности Java 8-16
Как уже упоминалось в самом начале этого руководства: в сущности все (если вы не будьте слишком требовательны) функции языка Java 8 работают в Java 14. То же самое касается всех других версий Java между ними.
В свою очередь, это означает, что знание всех языковых возможностей Java 8 создает хорошую базу в изучении Java, а все остальные версии (Java 9-16) в значительной степени дают дополнительные функции поверх этого базового уровня.
Вот краткий обзор того, что конкретные версии могут предложить:
Java 8 была массовым выпуском, и вы можете найти список всех функций на веб-сайте Oracle. Здесь я хотел бы упомянуть два основных набора функций:
Особенности языка: лямбды и т. д.
До Java 8 всякий раз, когда вы хотели создать экземпляр, например, нового Runnable, вы должны были написать анонимный внутренний класс, например, так:
С лямбдами тот же код выглядит так:
Вы также получили ссылки на методы, повторяющиеся аннотации, методы по умолчанию для интерфейсов и некоторые другие языковые функции.
Коллекции и потоки
В Java 8 вы также получили операции в функциональном стиле для коллекций, также известные как Stream API. Живой пример:
До Java 8, вам нужно было написать циклы for, чтобы что-то сделать с этим списком.
С помощью API Streams вы можете сделать следующее:
Если вы хотите больше практики на Java 8
Очевидно, что в рамках этого руководства я могу только дать краткий обзор каждого недавно добавленного Stream, Lambda или Optional метода в Java 8.
Если вам нужен более детальный, подробный обзор, включая упражнения, вы можете ознакомиться с моим курсом по основным функциям Java 8.
Java 9 также была довольно большой версией, с несколькими дополнениями:
Коллекции
Коллекции получили несколько новых вспомогательных методов для простого создания списков, наборов и карт.
Streams
Потоки получили несколько дополнений в виде методов takeWhile, dropWhile и iterate.
Optionals
Optionals получили метод ifPresentOrElse, которого очень не хватало.
Интерфейсы
Интерфейсы получили private методы:
Другие возможности языка
И пара других улучшений, таких как улучшенный оператор try-with-resources или расширения diamond оператора.
JShell
Наконец, в Java появилась оболочка, в которой вы можете попробовать простые команды и получить немедленные результаты.
HTTPClient
В Java 9 появилась первая предварительная версия нового HttpClient. До этого времени встроенная поддержка Http в Java была довольно низкоуровневой, и вам приходилось прибегать к использованию сторонних библиотек, таких как Apache HttpClient или OkHttp (кстати, отличные библиотеки!).
Project Jigsaw: модули Java и файлы Jar с несколькими выпусками
В Java 9 появилась система модулей Jigsaw, которая чем-то напоминает старую добрую спецификацию OSGI. Подробное описание Jigsaw не входит в задачи данного руководства — посмотрите предыдущие ссылки, чтобы узнать больше.
Если вы хотите больше практиковаться в Java 9
Опять же, это всего лишь краткий обзор функций Java 9, и если вам нужны более подробные объяснения и упражнения, ознакомьтесь с курсом основных функций Java 9.
Вывод типа локальной переменной: ключевое слово var
Чувствуете себя как в Javascript-е, не так ли? Однако Java все еще строго типизирован и var применяется только к переменным внутри методов (спасибо, dpash, за то, что снова указали на это).
Java 11 также была несколько меньшей версией с точки зрения разработчика.
Строки и файлы
Строки и файлы получили пару новых методов (здесь перечислены не все):
Запустить исходные файлы
Начиная с Java 10, вы можете запускать исходные файлы Java без предварительной их компиляции. Шаг к написанию сценариев.
Вывод типа локальной переменной (var) для лямбда-параметров
В заголовке сказано все:
HttpClient
HttpClient из Java 9 в его последней, не предварительной версии.
Другие вкусности
Flight Recorder (Регистратор полетов), сборщик мусора No-Op, Nashorn-Javascript-Engine объявлен deprecated (устаревшим) и т.д.
В Java 12 появилось несколько новых функций и исправлений, но здесь стоит упомянуть только поддержку Unicode 11 и предварительный просмотр нового выражения switch, которое вы увидите в следующем разделе.
Вы можете найти полный список возможностей здесь, но, по сути, вы получаете поддержку Unicode 12.1, а также две новые или улучшенные превью функции (могут быть изменены в будущем):
Switch выражение (Preview — предварительная версия)
Switch выражения теперь могут возвращать значение. И вы можете использовать лямбда-стиль синтаксиса для своих выражений, без проблем с ошибками:
Старые операторы switch выглядели так:
В то время как в Java 13 операторы switch могут выглядеть так:
Многострочные строки (предварительная версия)
Наконец-то, вы можете сделать это на Java:
Java 14 и далее
Switch выражения (стандартное)
Switch выражения, которые были превью функцией в версиях 12 и 13, теперь стандартизированы.
В настоящее время существуют классы Records (записей), которые помогают облегчить задачу написания большого количества шаблонов с использованием Java.
Взгляните на этот класс до Java 14, который содержит только данные, (потенциально) методы получения / установки, equals / hashcode, toString.
С записями теперь это можно записать так:
Опять же, это предварительная версия, которая может быть изменена в будущих выпусках.
Полезные исключения NullPointerExceptions
Наконец, исключения NullPointerExceptions описывают, какая именно переменная имела значение NULL.
Сопоставление с образцом для InstanceOf (предварительная версия)
Раньше вам приходилось выполнять cast ваших объектов внутри instanceof следующим образом:
Теперь вы можете сделать это, эффективно сбросив гипс.
Инструмент для упаковки (инкубатор)
Существует инструмент jpackage (инкубатор), который позволяет упаковать ваше Java-приложение в пакеты для конкретной платформы, включая все необходимые зависимости.
Сборщики мусора
Сборщик мусора Concurrent Mark Sweep (CMS) был удален, и был добавлен экспериментальный сборщик мусора Z.
Java 15
Текстовые блоки / многострочные строки
Представленные в качестве экспериментальной функции в Java 13 (см. Выше), многострочные тексты теперь готовы к работе.
Если вы когда-либо хотели иметь еще более четкое представление о том, кому разрешено создавать подклассы ваших классов, теперь есть такая sealed функция.
Записи и сопоставление с образцом
Функции Records и Pattern Matching из Java 14 (см. Выше) все еще находятся в предварительной версии и еще не доработаны.
Движок JavaScript Rhinoceros
После устаревания в Java 11 механизм Nashorn Javascript Engine был окончательно удален в JDK 15.
ZGC: готово к продакшн
Z Garbage Collector не маркирован экспериментальное больше. Теперь он готов к использованию в продакшн.
Java 16
Каналы сокетов домена Unix
Теперь вы можете подключаться к сокетам домена Unix (также поддерживаются macOS и Windows (10+).
Планируемая замена JNI (Java Native Interface), позволяющая выполнять привязку к собственным библиотекам (подумайте о C).
Записи и сопоставление с образцом
Запечатанные классы
Запечатанные классы (начиная с Java 15, см. Выше) все еще находятся в предварительной версии.
Java 17 и новее
Будет рассмотрено здесь, как только они будут выпущены. Зайдите в ближайшее время.
Заключение
К настоящему времени у вас должен быть довольно хорошее представление о нескольких вещах:
Как установить Java, какую версию получить и где ее получить (подсказка: AdoptOpenJDK).
Что такое дистрибутив Java, какие существуют и в чем различия.
Каковы различия между конкретными версиями Java.
Отзывы, исправления и ваш вклад всегда приветствуются! Просто оставьте комментарий внизу.
Спасибо за прочтение!
Благодарности
Стивен Колеборн, написал фантастическую статью о различных доступных дистрибутивах Java.