Java 10 General Availability

2angftoxwh_stepvtvcc6kswfje.png

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


Последнюю полвину года мы подробно обсуждали здесь новшества Java 10 и знаем их наизусть.
Но было бы странно, если самая главная Java-новость за полгода не появилась бы в этом хабе.
Как говорится, просто оставлю это здесь. Вперёд к приключениям!


Действительно вышла в срок?

Да, действительно. Релиз сделали из 46 билда, и собрали день назад, глядите:


$ java -version
openjdk version "10" 2018-03-20
OpenJDK Runtime Environment 18.3 (build 10+46)
OpenJDK 64-Bit Server VM 18.3 (build 10+46, mixed mode)


Долгий путь к релизу

На самом деле, нет. Это самый быстрый полноценный релиз в истории!


Раньше план публиковался на странице проекта, но больше он нам не понадобится. Все этапы успешно выполнены.


5tsbr4ccc1uv6mj4kxutkyi-txa.png

  • 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




И что, всё хорошо?

В основном, да. В этом релизе разработчики фокусировались на починке только тех багов, которые являются совершенно критичными для успеха Java 10. Все задачи, относящиеся к другим релизам Java, даже с высшим приоритетом, отложены.


Но какой же релиз без хорошего факапа? Тагир Валеев (lany) через считаные часы опубликовал в своём твиттере новость об эпическом новом баге в компиляторе.


4vj2ln3ekslrmnd2bgzt--f-huk.png

Баг уже обсуждают в рассылке и ведётся работа по его починке.


Вот этот код, можно вставить и проверить:


public class Main {
    void m() {
        var s = java.util.List.of("a", 1);
    }
}


Проблема проявляется только только при включённом флаге -g, который говорит о необходимости генерации отладочной информации.


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

JEP 286:  Local-Variable Type Inference.

Локальный вывод типов с помощью var. Неоднозначная фича. Регулярно вызывает бурления в рассылке.


Пример кода:


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


Бородатый анекдот в тему.
Заходит джавист в столовую и говорит: дайте, пожалуйста, Борщ борщ нью Борщ!




5c9kfg_tcnwvsblll10oh8cauxa.png

JEP 296: Консолидация леса исходников JDK в едином репозитории.

Широкой общественности обычно не интересно, разве что ты собираешь OpenJDK из исходников. Интересней то, что чем меньше хаоса в проекте, тем более качественный получается продукт.




whydvrhimz3l8rrswtxfqu0xh2w.png

JEP 304:  Garbage-Collector Interface.

Улучшение изоляции основных исходников от GC путём создания хорошего чистого интерфейса для GC. В последнее время стало весьма популярным писать свои GC: на подходе у нас Shenandoah, ZGC, Epsilon. Чтобы поддержать эти благие начинания, разработчикам OpenJDK пришлось конкретно разгрести свалку в коде, чтобы не только максимально упроситить создание новых GC, но и дать возможность быстро отключать ненужные GC из сборки. Один из основных критериев успеха — отсутствие просадки по перфомансу после всех этих рефакторингов.




cqjjzl7glxagqav4g42tko666dg.png

JEP 307:  Parallel Full GC for G1.

CMS выбросили на мороз, и всё интересное в общеупотребительной (не низкопаузной) сборке мусора теперь происходит в 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).




c27qztyr0npyoxar2fex1h5hple.png

JEP 310: Application Class-Data Sharing.

Чтобы ускорить запуск и уменьшить количество используемой памяти, предлагается расширить существующую фичу под названием Class-Data Sharing («CDS») возможностью упаковки классов в общий архив.


Если совсем коротко, то вот так архив вначале создаётся, а потом используется при запуске:


java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=hello.lst -XX:SharedArchiveFile=hello.jsa -cp hello.jar

java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa -cp hello.jar HelloWorld




xdsrvele3tlfforsyry-di5wg8q.png

JEP 312:  Thread-Local Handshakes.

Возможность выполнять колбэк на тредах, не делая глобальный для JVM сейфпоинт. Фича позволяет дешёво останавливать одиночные треды, а не только «всё или ничего». Это низкоуровневая системная фича, вручную ей воспользоваться нельзя, но можно радоваться автомагически возросшей производительности программ.




0cm6efajeijez6rcyc_lqhccfi8.png

JEP 313: Remove the Native-Header Generation Tool.

Утилита javah больше не нужна, потому что нативные заголовки теперь может делать javac (начиная с JDK8, на самом деле).


javah была утилитой, генерирующей сишные заголовочные файлы и исходники, необходимые для использования нативных методов. Сгенерированные ей файлы предназначены для использования в программах, написанных на Си, чтобы обращаться к экземплярам джавовых объектов из неуправляемого нативного кода. В .h-файле определяется структура, которая выглядит примерно как класс, которым мы собираемся управлять. Поля структуры — переменные экземпляра класса. Тем не мнее, в JNI использование подобных стабов не является обязательным.




3bvdimq3kzcvoa93bzvsq8avfew.jpeg

JEP 314:  Additional Unicode Language-Tag Extensions.

Поддержка новых расширений Unicode: cu (currency type), fw (first day of week), rg (region override), tz (time zone).




hu0hb7zxew83alz70sj2asrtbec.jpeg

JEP 316:  Heap Allocation on Alternative Memory Devices.

HotSpot VM теперь может выделять хиповую память на других девайсах, например, на NV-DIMM. Некоторые операционки уже умеют выделять не-DRAM память, помещая её на файловую систему, например, NTFS DAX и ext4 DAX. Добавляется опция ` -XX: AllocateHeapAt=.



0avbebly6ap9or0ksoxo3-ywsai.jpeg

JEP 317:  Experimental Java-Based JIT Compiler.

Graal, можно использовать как основной JIT-компилятор. Объяснять, что такое Graal — очень долго, поэтому вкратце. Под брендом Graal сейчас объединено несколько направлений: Graal Compiler, SubstrateVM, Truffle, различные языки для него («Graal polyglot runtime»). В данном случае имеется в виду именно Compiler. На некоторых тестах, типа Scala DaCapo, грааль позволяет получить почти двухкратную производительность по сравнению с C2! Чтобы получить подобные чудесные результаты, необходимо иметь очень-очень много динамического кода и очевидно, наибольшую пользу тут извлекут программисты на Scala, Groovy, JavaScript, и т.п. Работает это чудо пока что только на 64-битных Linux и macOS.




oezdywvk7ccecftll3mhb7kzsle.jpeg

JEP 319:  Root Certificates.

В JDK имеется кейстор cacerts, который нужен для хранения корневых сертификатов. Но в OpenJDK он пока пустой. Поэтому ништяки типа TLS в OpenJDK по-умолчанию не работают. Теперь этот cacerts будет правильно сконфигурирован и заполнен, и ништяки начнут работать. Кроме того, это сгладит разницу между OpenJDK и Oracle JDK.




s-h4xwvhqwwje9g46jxkldny2l4.png

JEP 322:  Time-Based Release Versioning.

Feature releases будут добавлять новые фичи. Update releases будут только чинить баги.


Ну и конечно же,


$ java -version
openjdk version "10" 2018-03-20
OpenJDK Runtime Environment 18.3 (build 10+46)
OpenJDK 64-Bit Server VM 18.3 (build 10+46, mixed mode)




Не всё есть в JEP

В багтрекере и рассылке можно увидеть большое количество изменений, которые не получили такую широкую огласку, как основные JEP.


По этому поводу Тагир Валеев (lany) недавно написал очень хорошую статью: https://habrahabr.ru/post/349868/. Дублировать её содержимое нет смысла, нужно пройти по ссылке и прочитать.


Что дальше?

Необходимо взять JDK 10 и начать миграцию на него своего кода!


Ссылка на загрузку: http://jdk.java.net/10/.


Минутка рекламы. Как вы, наверное, знаете, мы делаем конференции. Ближайшая конференция по Java — JPoint 2018. Она пройдет 6–7 апреля 2018 года в Москве. В докладах часто упоминаются вопросы перехода на новые версии Java. Какие доклады там бывают — можно посмотреть в нашем архиве на YouTube или прочитать в хаброблоге. Кроме того, можно будет вживую пообщаться с докладчиками и лучими экспертами по Java-платформе в специальных дискуссионных зонах после каждого доклада. Короче, заходите, мы вас ждём.

© Habrahabr.ru