Первый релиз-кандидат OpenJDK 10!
Ссылка для скачивания: http://jdk.java.net/10/.
Изменения, которые появятся в этом релизе
JEP 286: Local-Variable Type Inference
Локальный вывод типов с помощьюvar
. Неоднозначная фича. Регулярно вызывает бурления в рассылке.var list = new ArrayList
(); // infers ArrayList var stream = list.stream(); // infers Stream - JEP 296: Консолидация леса исходников JDK в едином репозитории
Наводится порядок в репозиториях. Широкой общественности обычно не интересно. - JEP 304: Garbage-Collector Interface
Улучшить изоляцию основных исходников от GC путём создания хорошего чистого интерфейса для GC. - JEP 307: Parallel Full GC for G1
Release Note: JEP 307: Parallel Full GC for G1: «Коллектор G1 создан для того, чтобы обходиться без full GC, но когда параллельная сборка не может утилизировать память достаточно быстро, происходит возвращение к full GC. Старая реализация full GC в G1 использовала однопоточный алгоритм mark-sweep-compact. После реализации JEP-307, full GC параллелизовался и стал использовать то же количество параллельных тредов-воркеров, как в young и mixed». (Напоминаю, что young GC обрабатывает только регионы young/survivor, mixed — ещё и old, full — весь хип, young/tenured). - JEP 310: Application Class-Data Sharing
Чтобы ускорить запуск и уменьшить количество используемой памяти, предлагается расширить существующую фичу под названием Class-Data Sharing («CDS») возможностью упаковки классов в общий архив. - JEP 312: Thread-Local Handshakes
Возможность выполнять колбэк на тредах, не делая глобальный для JVM сейфпоинт. Фича позволяет дешёво останавливать одиночные треды, а не только «всё или ничего». - JEP 313: Remove the Native-Header Generation Tool (javah)
Утилитаjavah
больше не нужна, потому что нативные заголовки теперь может делать javac (начиная с JDK8, на самом деле) - JEP 314: Additional Unicode Language-Tag Extensions
Поддержка новых расширений Unicode: cu (currency type), fw (first day of week), rg (region override), tz (time zone). - JEP 316: Heap Allocation on Alternative Memory Devices
HotSpot VM теперь может выделять хиповую память на других девайсах, например, на NV-DIMM. Некоторые операционки уже умеют выделять не-DRAM память, помещая её на файловую систему, например, NTFS DAX и ext4 DAX. Добавляется опция-XX:AllocateHeapAt=
. - JEP 317: Experimental Java-Based JIT Compiler
Graal, можно использовать как основной JIT-компилятор. Это делается в качестве эксперимента, и можно включить только на Linux/x64.» - JEP 319: Root Certificates
В JDK имеется кейсторcacerts
, который нужен для хранения корневых сертификатов. Но в OpenJDK он пока пустой. Поэтому ништяки типа TLS в OpenJDK по-умолчанию не работают. Теперь этотcacerts
будет правильно сконфигурирован и заполнен, и ништяки начнут работать. Кроме того, это сгладит разницу между OpenJDK и Oracle JDK. - JEP 322: Time-Based Release Versioning
Feature releases будут добавлять новые фичи. Update releases будут только чинить баги.
План релизов
Для JDK10 план выглядит так:
(Подробно все фазы объясняются в отдельном документе)
- 2017/12/14 Первая фаза замедления
- 2018/01/11 All Tests Run
- 2018/01/18 Вторая фаза замедления
- 2018/02/08 Первый Release Candidate
---вы находитесь здесь---
- 2018/02/22 Окончательный Release Candidate
- 2018/03/20 General Availability
Но как же… Там же ещё вагон багов?
Существует документ о том, каким требованиям должен удовлетворять JDK 10, чтобы стать успешным релиз-кандидатом. Смысл этой фазы процесса в том, чтобы сконцентрироваться на починке только тех багов, которые являются совершенно критичными для успеха проекта. Дальше я опишу, как эти требования выглядят для самих разработчиков OpenJDK.
Каждый баг имеет приоритет, начиная от P1 (для самых важных багов) и заканчивая P5 (для наименее важных). Конкретные критерии выбора приоритета зависят от конкретного проекта.
Формально список требований к RC выглядит вот так:
- Нужно починить все баги уровня P1, которые появились в JDK 10 и которые критичны для успешного выпуска релиза.
- Нужно отстраниться от починки P1 багов, которые добавились не в JDK 10, которые не критичны для успешного выпуска релиза, но которые изначально считали приуроченными именно к выпуску JDK 10.
- Явным образом отложить все P1 баги, которые относятся к JDK 10, но не являются критичными, или которые, по какой-то очень существенной причине, в этом релизе починить невозможно.
Любые баги уровней P2-P5 нужно отложить до следующих релизов, вне зависимости, попали ли они уже в код продукта, в тесты или документацию. В том числе, все фиксы с метками noreg-doc
и noreg-test
теперь должны явным образом подтверждаться и иметь уровень P1.
Нет никакого смысла явным образом откладывать непочиненные баги уровней P2-P5.
Начиная с этого момента, новые сборки будут появляться каждую неделю лишь в том случае, когда для этого есть необходимость.
Баги уровня P1
Обновлённый список багов можно найти здесь: http://j.mp/jdk-rc. Если кто-то из разработчиков OpenJDK отвечает за баг из этого списка, то он должен сделать одно из следующих действий:
- Разработать исправление бага и потом запросить подтвреждение на интеграцию этого исправления; или
- Если баг появился не в JDK 10 (эта информация есть в поле «Affects Version»), тогда можно либо удалить его из списка, просто очистив поле «Affects Version», либо вписать туда
tbd_feature
(если это стоит исправлять только в мажорном релизе), либо вписать тудаtbd_update
(если исправление стоит делать в любом релизе), либо вписать туда номер конкретного релиза; или - Если баг появился в JDK 10, но не является критичным или не может быть починен вовремя, то можно попросить, чтобы этот баг явным образом отложили с помощью соответствующего процесса, который мы ранее проверили на фазе замедления RDP-1.
В любом случае, не следует изменять приоретит бага только для того, чтобы вынести его из списка. Приоритет бага должен отражать важность починки вне зависимости от какого-то конкретного релиза, и такая практика поддерживается в течение многих лет развития JDK.
Баги уровней P2-P5
Release Candidate содержит только баги уровня P1. Баги уровня P2-P5 — не релевантны для общего статуса релиза, начиная с текущего момента и далее. Вне зависимости от того, в каком именно релизе их хотели исправить изначально. Поэтому с багами P2-P5 не имеет смысла делать что-то особенное. Не нужно их откладывать (явно, с помощью соответствующей процедуры, или неявно, изменяя поле «Fix Version»). Тем не менее, можно изменить значение этого поля на tbd_feature
или tbd_update
, если это может оказаться полезным для будущей работы.
Баги P2-P5, которые направлены только на тесты или документацию, исправить больше не получится.
Будем ли мы пользоваться Десяткой, когда она выйдет?
Скорее всего, да. Обычные релизы не являются экспериментальными, это полноценные релизы с как минимум шестимесячной поддержкой от Oracle. Их отличие от LTS — только в сроке поддержки, которая для LTS будет не менее чем 3 года. Предположительно, релизы будут появляться в марте и сентябре.
Подтверждающий слайд Марка Рейнхолда с конференции FOSDEM'18:
Минутка рекламы. По поводу всех важных JEPов мы постараемся выпустить отдельные статьи на Хабре, в блоге JUG.ru Group. Отдельные вещи мы выносим на конференции, например, Christian Thalinger рассказывает про Graal, а Volker Simonis — про Application Class-Data Sharing. Видео будет через несколько месяцев после конференции, но если прийти туда вживую — можно пообщаться непосредственно с разработчиками всех этих технологий.