Первый релиз-кандидат OpenJDK 10!

a31n1qxwaijksrj_7xeiknemkey.png

Ссылка для скачивания: 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:


ylczhnsuobuizyb3ibdk224lkmu.png

Минутка рекламы. По поводу всех важных JEPов мы постараемся выпустить отдельные статьи на Хабре, в блоге JUG.ru Group. Отдельные вещи мы выносим на конференции, например, Christian Thalinger рассказывает про Graal, а Volker Simonis — про Application Class-Data Sharing. Видео будет через несколько месяцев после конференции, но если прийти туда вживую — можно пообщаться непосредственно с разработчиками всех этих технологий.

© Habrahabr.ru