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


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

                                                       


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


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


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

    • JEP 296: Консолидация леса исходников JDK в едином репозитории
      Наводится порядок в репозиториях. Широкой общественности обычно не интересно.
    • JEP 304Garbage-Collector Interface
      Улучшить изоляцию основных исходников от GC путём создания хорошего чистого интерфейса для GC.
    • JEP 307Parallel 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 312Thread-Local Handshakes
      Возможность выполнять колбэк на тредах, не делая глобальный для JVM сейфпоинт. Фича позволяет дешёво останавливать одиночные треды, а не только «всё или ничего».
    • JEP 313: Remove the Native-Header Generation Tool (javah)
      Утилита javah больше не нужна, потому что нативные заголовки теперь может делать javac (начиная с JDK8, на самом деле)
    • JEP 314Additional Unicode Language-Tag Extensions
      Поддержка новых расширений Unicode: cu (currency type), fw (first day of week), rg (region override), tz (time zone).
    • JEP 316Heap Allocation on Alternative Memory Devices
      HotSpot VM теперь может выделять хиповую память на других девайсах, например, на NV-DIMM. Некоторые операционки уже умеют выделять не-DRAM память, помещая её на файловую систему, например, NTFS DAX и ext4 DAX. Добавляется опция -XX:AllocateHeapAt=<path>.
    • JEP 317Experimental Java-Based JIT Compiler
      Graal, можно использовать как основной JIT-компилятор. Это делается в качестве эксперимента, и можно включить только на Linux/x64."
    • JEP 319Root Certificates
      В JDK имеется кейстор cacerts, который нужен для хранения корневых сертификатов. Но в OpenJDK он пока пустой. Поэтому ништяки типа TLS в OpenJDK по-умолчанию не работают. Теперь этот cacerts будет правильно сконфигурирован и заполнен, и ништяки начнут работать. Кроме того, это сгладит разницу между OpenJDK и Oracle JDK.
    • JEP 322Time-Based Release Versioning
      Feature releases будут добавлять новые фичи. Update releases будут только чинить баги.

    План релизов


    Для JDK10 план выглядит так:
    (Подробно все фазы объясняются в отдельном документе)



    ---вы находитесь здесь---



    Но как же… Там же ещё вагон багов?


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

    JUG.ru Group

    566,00

    Конференции для взрослых. Java, .NET, JS и др. 18+

    Поделиться публикацией
    Комментарии 30
      +1
      Будут ли патчи для сборки OpenJDK10 на FreeBSD?
        +2
        Ну ты спросил. :-)
        Официально, фокус отдаётся трём платформам: GNU/Linux, macOS и Windows. Все 64-битные. Windows несколько отстаёт (например, инфраструктура сборки там сильно хуже и требует Cygwin). Про FreeBSD ничего не знаю. Можешь попробовать собрать сам и рассказать о результатах на Хабре.
          –1
          зачем cygwin, когда есть wsl?
            +3
            зачем wsl, если есть msys2? Но правда в том, что собирается нормально только под Cygwin (не помню почему, сейчас разбираться не буду)
        +1
        а чего во всех ссылках на roadmap jdk8 и 9? и будет ли valhalla? не вижу этого проекта в списке фич =(
          0
          Если ты про value types, то к 10 их сделать не успеют. Ссылки на описание этапов роадмапа ведут на 8, потому что написатели документации ленивые, лень копировать на новый урл :)
            0
            Но, не смотря на это, Valhalla`у можно попробовать с 10-кой, если у Вас Linux или Mac: jdk.java.net/valhalla
          +5
          Как обычно, напоминаю, что не все изменения сидят в JEP'ах. Особенно то что касается стандартной библиотеки. Добавлено много приятных мелочей. Коллекторы toUnmodifiableList/Map/Set, например. Или методы вроде List.copyOf, которые создают неизменяемую копию коллекции (или не создают, если на вход уже подан неизменяемый список).
            0
            Или поддержка Докера. Да, осознал ошибку(
          0
          Извините, не мог бы кто-нибудь пояснить упоминание «HotSpot VM» в статье про OpenJDK? Я всегда думал что HotSpot — это название оракловой JVM. (Не троллинг, мне реально интересно)
            +2
            OpenJDK и Oracle JDK — это почти одно и то же (особенно теперь, когда было объявлено об открытии в опенсорс JFR, JMC, ZGC, AppCDS итп)
              0

              HotSpot всегда входил в OpenJDK

                0
                Совсем запутали! Я то думал что существование OpenJDK обусловленно особой лицензией на распространнение бесплатного софта, которое ораклованя(сановская) джава не саппортит в полном объёме. Какой же смысл основывать полностью открытый софт на несовсем полностью открытом?..
                  0
                  Oracle почти закончили перевод Java в open source. Скорее всего, уже в этом году Oracle JDK станет просто «commercial long term support offering».
                  0
                  А не наоборот ли?
                  +2
                  HotSpot — это название виртуальной машины. А OpenJDK — это название Java Development Kit, включающего в себя саму виртуальную машину, стандартную библиотеку классов, компилятор, отладчик, упаковщик, профайлер и множество других утилит разработчика, а также документацию.
                    +1
                    Кстати, в OpenJDK можно использовать IBM'овскую виртуальную машину J9, вместо HotSpot.
                      –1
                      Хорошо, а что же тогда я скачиваю с сайта Оракла под релизом JDK? Ведь когда я запускаю -version, я получаю:
                      C:\>java -version
                      java version «9.0.4»
                      Java(TM) SE Runtime Environment (build 9.0.4+11)
                      Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
                      И чем этот оракловый релиз отличается от OpenJDK? Почему у меня на OpenJDK tomcat валится с OoM на SSL, в то время как оракловая бегает без фейлов?
                        +1
                        Вот что по этому поводу писал пару лет назад Henrik Stahl:
                        Q: What is the difference between the source code found in the OpenJDK repository, and the code you use to build the Oracle JDK?

                        A: It is very close — our build process for Oracle JDK releases builds on OpenJDK 7 by adding just a couple of pieces, like the deployment code, which includes Oracle's implementation of the Java Plugin and Java WebStart, as well as some closed source third party components like a graphics rasterizer, some open source third party components, like Rhino, and a few bits and pieces here and there, like additional documentation or third party fonts. Moving forward, our intent is to open source all pieces of the Oracle JDK except those that we consider commercial features such as JRockit Mission Control (not yet available in Oracle JDK), and replace encumbered third party components with open source alternatives to achieve closer parity between the code bases.

                        Возможно, проблемы с SSL у вас возникают потому, что
                        В JDK имеется кейстор cacerts, который нужен для хранения корневых сертификатов. Но в OpenJDK он пока пустой. Поэтому ништяки типа TLS в OpenJDK по-умолчанию не работают. Теперь этот cacerts будет правильно сконфигурирован и заполнен, и ништяки начнут работать. Кроме того, это сгладит разницу между OpenJDK и Oracle JDK.
                          0
                          Вот теперь спасибо за пояснения. Привильно ли я понял, что до какого-то этапа OracleJDK и OpenJDK собираются одинаково, затем всё что можно открыть называют OpenJDK, а остальное называют OracleJDK? Причём виртуальная машина у них по умолчанию одинакова и называется HotSpot?
                            0
                            Oracle JDK собирают из исходного кода OpenJDK с небольшими добавками. Но вскоре и исходный код этих добавок переедет в OpenJDK, а Oracle JDK будет отличаться только наличием технической поддержки.
                              0
                              Теперь понятно. Спасибо.
                                0
                                Не знаешь, как решён вопрос с патентами на всякие сглаживания шрифтов?
                    +2
                    Чего я так и не понял, так это успели ли закончить асинхронный JDBC, как обещали?
                    +1

                    Я, если честно, слегка в шоке от политики партии "ничего не чинить, кроме того, что не чинить уж совсем стыдно". Насколько я понимаю, это означает, что всё, кроме LTS будет адово бажным, а стратегия Оракла в рамках шестимесячной поддержки сведётся к "дотянуть до EOL и советовать пересесть на LTS".

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое