JDK 9 — письмо Санте ?!

Как всем известно, зима (особенно время перед Рождеством) — подходящее время для мечтаний и надежды на момент, когда сны кажутся осязаемыми. Момент, когда дети и взрослые пишут на бумаге или в своих мыслях вымышленные или настоящие письма Деду Морозу, надеясь, что их мечты станут реальностью. Это бросается в глаза, так как даже люди, стоящие за OpenJDK, выразили свои пожелания (о Java) в первый день декабря, когда они опубликовали обновленный список JEP. Подожди, пока не волнуйся… как мы с горечью знаем, они могут стать реальностью где-то в начале 2016 года. Или, по крайней мере, это план, и история показала нам, что значит придерживаться плана.

Конечно, наличие JEP в вышеупомянутом списке не означает, что окончательный выпуск будет содержать его, как четко объясняет диаграмма процесса JEP, но ради зимних сказок мы пройдемся по списку и предоставим краткое описание, какова цель каждого предмета.

Отказ от ответственности: список JEP является движущейся целью, так как после публикации этой статьи список изменился хотя бы один раз.

JEP 102: обрабатывать обновления API

Тем из вас, кому повезло не так уж и хорошо, кажется, что Санта наказал вас, и вы имели удовольствие работать с API Java-процесса и, конечно, встретили его ограничения. После изменений в JDK 7 текущий JEP улучшит этот API еще больше и даст нам возможность:

• чтобы получить pid (или эквивалент) текущей виртуальной машины Java и pid процессов, созданных с помощью существующего API
• получить / установить имя процесса текущей виртуальной машины Java и процессы, созданные с помощью существующего API (где это возможно)
• перечислить виртуальные машины и процессы Java в системе. Информация о каждом процессе может включать его pid, имя, состояние и, возможно, использование ресурса.
• иметь дело с деревьями процессов, в частности с некоторыми средствами уничтожить дерево процессов
• иметь дело с сотнями подпроцессов, возможно, мультиплексировать потоки вывода или ошибок, чтобы избежать создания потока для подпроцесса

Я не знаю о вас, но я определенно могу найти, по крайней мере, пару сценариев, где я мог бы эффективно использовать некоторые из этих функций, так что пальцы скрещены.

JEP 143: улучшить блокировку по соглашению

Я имел счастье и удовольствие присутствовать на семинаре по производительности с Питером Лоури в другие дни, и одним из правил большого пальца настройки производительности Java было: чем меньше параллельное приложение, тем оно более производительное. С этим улучшением, правила настройки производительности, возможно, должны будут найти другое правило большого пальца, поскольку в этом JEP реализована задержка использования мониторов в java. Чтобы быть более точным, цели:

• Переупорядочение полей и выравнивание строк кэша
• Ускорить PlatformEvent::unpark()
• Операции ввода быстрого Java-монитора
• Быстрые операции выхода из монитора Java
• Быстрый Java-монитор notify / notify notifyAll операции
• Улучшения адаптивного вращения и SpinPause на SPARC

JEP 158: унифицированное ведение журнала JVM

Название вроде говорит само за себя. Если вы работаете с корпоративными приложениями, вам приходилось иметь дело, по крайней мере, один или два раза с журналом gc, и я полагаю, что по крайней мере поднял бровь (если не оба) при просмотре объема информации и способа ее представления там. Ну, если вам «повезло», вы, вероятно, мигрировали между версиями JVM, а затем определенно хотели / нуждались в еще двух бровях, чтобы поднять, когда вы поняли, что у парсеров, которые вы создали для предыдущей версии, есть проблемы, связанные с текущей версией Ведение журнала JVM. Я полагаю, что могу продолжить, почему это плохо, но давайте сконцентрируемся на улучшениях, так что, надеюсь, к следующему выпуску у нас будет повод жаловаться, что раньше это было лучше.

Ведение журнала gc, похоже, пытается согласоваться с другими структурами ведения журнала, которые мы могли бы использовать, например, log4j. Таким образом, он будет работать на разных уровнях с точки зрения критичности регистрируемой информации (ошибки, предупреждения, информация, отладка, трассировка), их целью производительности является эта ошибка и предупреждение, чтобы не оказывать какого-либо влияния на производительность в производственных средах, информация, подходящая для производственных сред в то время как отладка и трассировка не имеют никаких требований к производительности. Строка журнала по умолчанию будет выглядеть следующим образом:

[gc][info][6.456s] Old collection complete

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

Единственный и, вероятно, самый большой недостаток этого JEP — то, что он нацелен только на обеспечение механизмов регистрации и не обязательно означает, что журналы также улучшатся. Чтобы иметь красивые бревна, о которых мы мечтаем, возможно, нам нужно подождать еще немного.

JEP 165: управление компилятором

Как вы, вероятно, знаете, платформа java использует JIT-компиляторы для обеспечения оптимального запуска написанного приложения. Два существующих компилятора с интуитивно понятными именами C1 и C2 соответствуют клиенту (опция -client) и соответственно приложению на стороне сервера (опция -server). Заявленные цели этого JEP — повысить управляемость этих компиляторов:

• Мелкозернистое и зависимое от метода управление компилятором JVM (C1 и C2).
• Возможность изменять параметры управления компилятором JVM во время выполнения.
• Нет снижения производительности.

JEP 197: кеш сегментированного кода

Похоже, что производительность JVM нацелена в будущем выпуске Java, поскольку текущий JEP предназначен для оптимизации кеша кода. Цели:

• Отдельный непрофильный, профилированный и непрофилированный код
• Более короткое время развертки благодаря специализированным итераторам, которые пропускают не-методический код
• Сократить время выполнения некоторых тестов с интенсивным сбором
• Лучшее управление объемом памяти JVM
• Уменьшить фрагментацию высокооптимизированного кода
• Улучшите локальность кода, потому что код того же типа, вероятно, будет доступен близко во времени
  • Лучшее поведение iTLB и iCache
• Создать базу для будущих расширений
  • Улучшено управление разнородным кодом; например, Суматра (код GPU) и скомпилированный код AOT
  • Возможность детальной блокировки на кучу кода
  • Будущее разделение кода и метаданных (см. JDK-7072317 )

Первые две объявленные цели, с моей точки зрения, весьма интересны, поскольку две из них могут значительно улучшить время развертки кэша кода, просто пропуская области, не относящиеся к методам — ​​области, которые должны существовать во всей среде выполнения JVM.

JEP 198: легкий JSON API

Присутствие этого улучшения не должно быть сюрпризом, но для меня удивительно, что в JDK это произошло не так быстро, поскольку JSON заменил XML в качестве «языка общения» в Интернете, а не только для реактивного JS-интерфейса. — заканчивается, но и для структурирования данных в базах данных NoSQL. Заявленные цели этого JEP:

• Разбор и генерация JSON RFC7159 .
• Функциональность отвечает потребностям разработчиков Java, использующих JSON.
• API-интерфейсы синтаксического анализа, которые позволяют выбирать поток синтаксического анализа, поток событий (включая контекст иерархии документов) или представления неизменяемого древовидного представления документов и потоков данных JSON.
• Полезное подмножество API для компактных профилей и Java ME.
• Построение дерева неизменных значений с использованием API в стиле Builder.
• API стиля генератора для вывода потока данных JSON и «литералов» JSON.
• API преобразователя, который принимает в качестве входных данных существующее дерево значений и создает новое дерево значений в качестве результата.

Кроме того, намерение состоит в том, чтобы выровнять с JSR 353 . Даже если будущий JSON будет иметь ограниченные функциональные возможности по сравнению с уже существующими библиотеками, он обладает конкурентным преимуществом интеграции и использования недавно добавленных функций из JDK 8, таких как потоки и лямбды.

JEP 199: интеллектуальная компиляция Java, вторая фаза

Sjavac — это обертка для уже известного javac, обертка, предназначенная для повышения производительности при компиляции проектов большого размера. Как и на текущем этапе, у проекта есть проблемы со стабильностью и переносимостью, основная цель состоит в том, чтобы исправить данные проблемы и, вероятно, сделать его инструментом сборки по умолчанию для проекта JDK. Растянутой целью было бы сделать инструмент готовым к использованию для проектов, отличных от JDK, и, возможно, интеграции с существующей цепочкой инструментов.

JEP 201: модульный исходный код

Первые шаги в направлении реализации проекта Jigsaw с намерением реорганизовать исходный код в виде модулей, улучшая инструмент для сборки модулей и соблюдая границы модуля.

JEP 211: предупреждение Elide об устаревших отчетах об импорте

Цель этого JEP — облегчить очистку больших кодовых баз от предупреждений lint. Предупреждения об устаревании при импорте не могут быть подавлены с @SuppressWarnings аннотации @SuppressWarnings , в отличие от использования устаревших элементов в коде. В больших базах кода, таких как JDK, устаревшая функциональность часто должна поддерживаться в течение некоторого времени, и простой импорт устаревшей конструкции не оправдывает предупреждающее сообщение, если все виды использования устаревшей конструкции являются преднамеренными и подавлены.

JEP 212: разрешение предупреждений Линт и Доклинт

Поскольку дата обеда для JDK 9 — начало 2016 года, этот JEP идеально подходит для этого времени года и соответствующей работы по дому: весенняя уборка. Основная цель этого состоит в том, чтобы иметь чистую компиляцию под опцией javac lint (-Xlint: all) по крайней мере для основных пакетов платформы.

JEP 213: фрезерная монета проекта

Цель монеты проекта, начиная с JDK 7, заключалась в том, чтобы принести немного синтаксического сахара на языке java, чтобы принести новую одежду на зрелую платформу. Даже если это не принесло каких-либо улучшений в производительность языка, это повысило читабельность кода, следовательно, это принесло плюс одному из самых важных активов программного проекта, на мой взгляд, более читаемой базе кода.

Этот JEP нацелен на четыре изменения:

1. Разрешить @SafeVargs для закрытых методов экземпляра .
2. Разрешить использование эффективно-конечных переменных в качестве ресурсов в инструкции try-with-resources .
3. Разрешить алмаз с внутренними классами, если тип аргумента выведенного типа является denotable .
4. Завершите удаление, начатое в Java SE 8, подчеркивания из набора имен допустимых идентификаторов.

JEP 214: удалить комбинации GC, устаревшие в JDK 8

Весенняя очистка продолжается с удалением флагов JVM, которые устарели в выпуске Java 8, поэтому с выпуском 9 следующие опции больше не будут поддерживаться:

JEP 216: правильно обрабатывать импортные отчеты

Этот JEP нацелен на исправление javac для правильного принятия и отклонения программ независимо от порядка операторов import а также extends и implements предложения.

JEP 219: безопасность транспортного уровня дейтаграмм (DTLS)

Увеличивается число протоколов прикладного уровня, которые используют транспорт UDP, в частности, такие протоколы, как протокол инициации сеанса (SIP) и протоколы электронных игр, сделали проблемы безопасности выше, чем когда-либо, тем более что TLS можно использовать только над надежными протоколами, такими как TCP , Текущий JEP намеревается восполнить этот пробел, определив API для Datagram Transport Layer Security (DTLS) версий 1.0 ( RFC 4347 ) и 1.2 ( RFC 6347 ).

JEP 220: модульные изображения во время выполнения

Приходит как дополнительный шаг к JEP 201 с намерением реструктурировать JDK и среду выполнения для размещения модулей и повышения производительности, безопасности и удобства обслуживания. Определите новую схему URI для именования модулей, классов и ресурсов, хранящихся в образе времени выполнения, без раскрытия внутренней структуры или формата изображения. Пересмотреть существующие спецификации в соответствии с требованиями, чтобы учесть эти изменения.

JEP 224: HTML5 Javadoc

По мере того как стандартная версия HTML достигла версии 5, страницы Javadoc JDK также должны идти в ногу со временем, и, следовательно, обновляться с HTML 4.01.

JEP 231: удалить обновления API выбора версии JRE во время запуска

Удалите возможность запрашивать (с помощью -version 🙂 во время запуска JRE версию JRE, которая не запускается JRE. Удаление будет выполнено поэтапно: в версии 9 будет выдано предупреждение, а Java 10, вероятно, выдаст ошибку.

Это текущая форма списка улучшений, подготовленных для JDK 9, если честно, когда я впервые посмотрел на него, я был каким-то синим, но после прочтения в него я был довольно взволнован, поскольку кажется, что java еще не начал свой путь для другого приключения, и им нужна вся помощь, которую они могли получить. Так что, если вы хотите принять участие (пожалуйста, сделайте!), Более поздняя публикация в блоге о серии Java-адвента покажет вам, как принять участие. Представьте, что это корабль корабля кольца, но целью приключения является создание java, а не разрушение кольца … кем может быть мистер Фродо?