Ссылка для скачивания: 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>
javah
больше не нужна, потому что нативные заголовки теперь может делать javac (начиная с JDK8, на самом деле)-XX:AllocateHeapAt=<path>
.cacerts
, который нужен для хранения корневых сертификатов. Но в OpenJDK он пока пустой. Поэтому ништяки типа TLS в OpenJDK по-умолчанию не работают. Теперь этот cacerts
будет правильно сконфигурирован и заполнен, и ништяки начнут работать. Кроме того, это сгладит разницу между OpenJDK и Oracle JDK.Для JDK10 план выглядит так:
(Подробно все фазы объясняются в отдельном документе)
---вы находитесь здесь---
Существует документ о том, каким требованиям должен удовлетворять JDK 10, чтобы стать успешным релиз-кандидатом. Смысл этой фазы процесса в том, чтобы сконцентрироваться на починке только тех багов, которые являются совершенно критичными для успеха проекта. Дальше я опишу, как эти требования выглядят для самих разработчиков OpenJDK.
Каждый баг имеет приоритет, начиная от P1 (для самых важных багов) и заканчивая P5 (для наименее важных). Конкретные критерии выбора приоритета зависят от конкретного проекта.
Формально список требований к RC выглядит вот так:
Любые баги уровней P2-P5 нужно отложить до следующих релизов, вне зависимости, попали ли они уже в код продукта, в тесты или документацию. В том числе, все фиксы с метками noreg-doc
и noreg-test
теперь должны явным образом подтверждаться и иметь уровень P1.
Нет никакого смысла явным образом откладывать непочиненные баги уровней P2-P5.
Начиная с этого момента, новые сборки будут появляться каждую неделю лишь в том случае, когда для этого есть необходимость.
Обновлённый список багов можно найти здесь: http://j.mp/jdk-rc. Если кто-то из разработчиков OpenJDK отвечает за баг из этого списка, то он должен сделать одно из следующих действий:
tbd_feature
(если это стоит исправлять только в мажорном релизе), либо вписать туда tbd_update
(если исправление стоит делать в любом релизе), либо вписать туда номер конкретного релиза; илиВ любом случае, не следует изменять приоретит бага только для того, чтобы вынести его из списка. Приоритет бага должен отражать важность починки вне зависимости от какого-то конкретного релиза, и такая практика поддерживается в течение многих лет развития JDK.
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. Видео будет через несколько месяцев после конференции, но если прийти туда вживую — можно пообщаться непосредственно с разработчиками всех этих технологий.
К сожалению, не доступен сервер mySQL