Ссылка для скачивания: http://jdk.java.net/10/.

Изменения, которые появятся в этом релизе

• JEP 286: Local-Variable Type Inference
  Локальный вывод типов с помощью var. Неоднозначная фича. Регулярно вызывает бурления в рассылке.

  
  

  var list = new ArrayList<String>();  // infers ArrayList<String>
  var stream = list.stream();          // infers Stream<String>

  
  
• 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=<path>.
• 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. Видео будет через несколько месяцев после конференции, но если прийти туда вживую — можно пообщаться непосредственно с разработчиками всех этих технологий.