240 дней прошло с момента выпуска JEP 3: JDK Release Process, и адская машина по производству новых версий останавливаться не желает. А значит, настало время очередного релиз-кандидата. Это период, когда все мосты сожжены, баги с приоритетами P2-P5 уже ничего не значат, и дни до релиза сочтены.
Баги
Не все баги с приоритетом P1 закрыты. Ознакомиться с полным списком проблем можно в багтрекере. И тут нас ожидает самое странное: все они относятся строго к Swing при использовании GTKLookAndFeel.
- JSlider display issue with slider for GTKLookAndFeel;
- JScrollBar display issue with GTKLookAndFeel;
- JProgressBar display issue with GTKLookAndFeel;
- JOptionPane display issue with GTKLookAndFeel;
- JTextPane display issue with GTKLookAndFeel.
Уже мысленно сказали: «Да что с этими ребятами в Свинге не так?». На этот раз «виноваты» не они. Если кто вдруг не знает, Gtk — это свободный тулкит для разработки графических интерфейсов, особенно на операционной системе GNU/Linux для X11 и Wayland.
Начиная с Gtk 3.20 у них поменялся способ работы со многими стилями и виджетами. Вместо классов стилей и имен типов теперь используются имена элементов. Gtk 3.20 вышел 21 марта 2016 года, и это был очень масштабный релиз — 28933 коммита и Wayland по умолчанию. Вообще, весь Gnome стал выглядеть слегка по-другому.
Неудивительно, что в Swing могли кое-что забыть и не протестировать. Часть багов сдвинули в приоритете на P2 и перенесли на JDK 13. Например, вот этот баг про то, что Motif в MacOS, как бы помягче сказать, более не является столь актуальной графической средой:
Будет забавно, если на Хабре кто-то действительно всё ещё использует Motif и AWT. Надеюсь, двенадцатый JDK не отменят из-за этого, иначе это будет самый эпический фейл в джаве за всю её молодую новую релизную историю.
Фичи
JEP-ы в этом списке будут перечислены не по важности, а исключительно по порядковому номеру. Это чтобы вы вдруг не подумали, что Шенанда и JMH попали наверх из-за личных симпатий.
189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
Неплохо бы, чтобы оно произошло ещё год назад, и Шенанда попала в LTS. Ладно, дождались — и на том спасибо. Shenandoah — это низкопаузный коллектор, добивающийся своей низкопаузности за счёт многопоточной фазы эвакуации. Причем паузы не зависят от размера хипа, поэтому можно смело ворочить терабайтными хипами на проде.
230: Microbenchmark Suite
В JDK добавляется набор тестов, основанный на JMH, да и сам JMH тоже. Лежит в jdk/jdk/test/micro/org/openjdk/bench
. JMH — это фреймворк для создания, сборки, запуска и анализа микробенчмарков для Java и других JVM-языков, написанный сами понимаете кем. JMH сейчас де-факто является стандартом для микробенчмарков, и появление подобных JEP-ов — вопрос времени.
325: Switch Expressions (Preview)
Вместо тысячи описаний:
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};
334: JVM Constants API
Цель в том, чтобы предоставить набор типов для формального моделирования описаний классов, методов и других сущностей в рантайме и классфайле и натянуть их на основные классы вроде String
или Class
. Они живут в пакетах вроде java.lang.invoke.constant
и есть не просят, а на сам патч можно взглянуть здесь.
340: One AArch64 Port, Not Two
Старый порт arm64 выброшен на мороз, а вот 32-битный ARM и aarch64 — активно пилятся. За существование этих портов нужно благодарить в том числе компании RedHat и BellSoft (кстати, офис BellSoft расположен в Питере, рядом с бывшим офисом компании Oracle). К релизу JDK 12 мы постараемся получить от представителей компании более развёрнутый комментарий.
341: Default CDS Archives
Как фича CDS нам был давно доступен, но было непонятно, зачем каждый раз самостоятельно писать -Xshare:dump
, если дефолтный результат выполнения этой команды немножко предсказуем ещё на этапе создания дистрибутива JDK. Эту досадную оплошность починят в JDK 12, архив CDS будет генериться создателями дистрибутива, даже для ночных билдов (при условии что они 64-битные и нативные, не для кросс-компиляции).
344: Abortable Mixed Collections for G1
Эта фича нужна внутренним механизмам сборщика мусора G1, чтобы он чаще укладывался в требования по продолжительности паузы. Бывает так, что можно определить, когда G1 раз за разом неправильно оценивает сложность сборки, особенно для старых регионов. В этот момент можно испугаться и начать собирать инкрементально, шаг за шагом, и после каждого шага иметь возможность сборку прервать. Утверждается, что это позволит лучше укладываться в ожидаемое время сборки.
346: Promptly Return Unused Committed Memory from G1
Сейчас G1 отдаёт commited-память операционной системе или при full GC, или при параллельной сборке. И то и другое G1 всячески пытается избежать, за что ему спасибо. Но это же означает, что память пожирается как не в себя, и заставить G1 исторгнуть память обратно можно только каким-то внешним способом. Особенно это печально для всяких докеров и прочих хипстеров без терабайтов оперативной памяти на сервере. Вместо этого предлагается делать так же, как уже умеет Шенанда или GenCon из OpenJ9 — определять недостаточную утилизацию хипа и соответственно уменьшать его использование. На каких-то тестах на Томкате это позволило уменьшить расход памяти почти в два раза.
Что дальше
Это был обзор по верхам, а подробный разбор фич постараемся сделать ближе к релизу в виде отдельных статей — переводов JEP-ов, скринкастов с бенчмарками или ещё чего-то такого. Теперь надо ждать релиза, который намечен на 19 марта.
Минутка рекламы. Совсем скоро, 5-6 апреля, пройдёт конференция JPoint, на которой соберётся огромное количество людей, знающих толк в JDK и всевозможных новых фичах. Например, точно будет Саймон Риттер из Азула с докладом «JDK 12: Pitfalls for the unwary». Самое правильное место, чтобы обсудить свежий релиз! Подробней о JPoint можно узнать на официальном сайте.
Комментарии (16)
pmcode
14.02.2019 19:08+1А нет ли еще информации когда raw string literals завезут?
olegchir Автор
14.02.2019 20:33Я перестал следить, когда Гёц написал вот это. Нужен кто-то, кто читает amber-*. Может, lany знает?
pmcode
14.02.2019 21:27+1Вот же зануды какие :) Но большая доля правды там есть. Если ограничения языка не позволяют сделать template literals как JS, то достаточно будет и multiline strings, как в Python. Вот тут уж им точно никто не мешает. Хотя отсутствие необходимости экранировать обратный слэш тоже вкусно смотрится. Спасибо за ссылку.
dim2r
15.02.2019 11:17планируют ли checked arithmetics?
есть необходимость знать моменты порчи чисел, типа
int foo = Integer.MAX_VALUE + 1; --> trow exception
kzhyg
Что не так с AWT?
olegchir Автор
Вы используете чистый AWT для UI?
начать с того что, зайти в
java.awt.Component
и посчитать количество@deprecated
:)kzhyg
А почему вы отвечаете вопросом на вопрос?
На данный момент нет, всё на Swing'e. Но если понадобится использовать только нативные графические объекты или будет хост без поддержки Swing, то из двух зол — SWT и AWT — я выберу последнее. Софт на SWT слишком хрупкий и имеет проблемы с переносимостью. А JavaFX вообще не работает вне вылизанного окружения.
По поводу депрекации — вспомните историю API для работы со временем, сейчас там больше мёртвых классов, чем живых. Значит ли это, что от времени стоит отказаться? ;)
olegchir Автор
Я интерфейсы всегда делал на браузерном движке, поэтому не смогу поддержать дискуссию, наверное. С появлением Электрона для меня этот вопрос закрылся: интерфейс на Электроне с тем фреймворком, который сейчас наиболее модный, бэк на джаве или дотнете.
lazant
Да, при живом электроне писать десктоп на Java смысла нет, в большинстве случаев. Даже по потреблению памяти там показатели схожие получаются, а гибкость интерфейсов у web платформы мягко говоря лучше, не говоря уж о сообществе и выборе инструментов, один devtools чего стоит.
olegchir Автор
Ну такое, можно использовать браузер в javafx сразу же, как этот браузер у них перестанет течь. Сейчас нужно вручную юзать CEF, а это неприятно.