JEP 353 — Повторная реализация устаревшего API сокетов

JEP 353 охватывает новую реализацию Socket API. Если быть точнее, к основным библиотекам добавлена ​​дополнительная, более современная реализация Socket API (которая появилась в Java 1). Старый Socket API доступен через системное свойство JDK и класс PlainSocketImpl (но ненадолго).

Первая и, на мой взгляд, самая важная особенность новой реализации — сокеты опрашиваются в неблокирующем режиме, а доступ к ним осуществляется через операцию, по умолчанию ограниченную таймаутом. Почему это важно? По сути, это означает, что вы можете выполнять операции над объектом Socket, не дожидаясь ответа Socket, прежде чем выполнять дополнительную операцию над указанным Socket. Рассмотрим приложение, которое использует внешние API для подмножества своих функций. Если вы запускаете приложение с блокирующим сокетом, вам придется дождаться завершения операций с сокетом, прежде чем продолжить приложение. Но если вы инициируете соединение со службой API с помощью неблокирующего сокета и сохраняете результат в объекте Future‹›, вы можете продолжить шаги инициализации вашего приложения, не дожидаясь ответа. Это особенно удобно при разделении инициализации вашего приложения и сторонних зависимостей.

JEP 350 — динамические архивы CDS

Это конкретное усовершенствование изменяет JRE больше, чем что-либо еще; большинство разработчиков Java не заметят этого усовершенствования в своей повседневной разработке. Истоки этого JEP начинаются с Java 10, с JEP 310. Совместное использование данных классов существует со времен JDK 5, но для Java 10 оно было кодифицировано как «Совместное использование данных классов приложений». указанный разработчиком список классов совместно используется в файле архива. Затем этот архивный файл загружается и на него ссылается JVM. Если этот архивный файл состоит из 100 файлов классов, вы сэкономите JVM много времени и энергии, ссылаясь только на один файл. Это уменьшает объем используемой памяти и время загрузки приложений.

Итак, какая функция была добавлена ​​в CDS в Java 13? Java 13 представляет динамическое архивирование. До Java 13 создание архива CDS требовало выполнения нескольких шагов. Как указано в JEP 350, шаги следующие:

  1. Выполните один или несколько пробных запусков, чтобы создать список классов
  2. Дамп архива с использованием созданного списка классов
  3. Запуск с архивом
    Все эти шаги можно выполнить с помощью параметров интерфейса командной строки java. В зависимости от размера приложения выполнение этих команд может быть затруднено. Вот тут-то и появляется Dynamic CDS. Это усовершенствование выполняет шаг 1 в конце выполнения вашего приложения, скажем, в процессе сборки QA. Отсюда остается только создать файл архива и поместить его в конвейер CI/CD для развертывания. Ручные шаги, необходимые для создания списка классов, необходимого для создания архива, полностью отсутствуют в динамических архивах CDS.

JEP 351 — ZGC: отменить неиспользуемую память

ZGC был новым сборщиком мусора, представленным в Java в Java 11. Он был разработан для работы в средах с огромными требованиями к вычислительной мощности и памяти, значительно превышающими требования к настольным компьютерам. В то время как другие сборщики мусора имеют свои преимущества, ZGC — лучший выбор для приложений со значительными требованиями к памяти и вычислительным ресурсам.

Однако ZGC не безграничен. До Java 13 ZGC никогда не возвращал память ОС без перезагрузки. Эта функция является общей для большинства сборщиков мусора; большинство традиционных сборщиков мусора по умолчанию возвращают память ОС, поскольку они были разработаны для работы на обычном или даже встроенном оборудовании со строго ограниченными требованиями к памяти и вычислительным ресурсам. Невозможность вернуть память ОС может иметь серьезные последствия для производительности приложений. Однако, если мы рассмотрим происхождение ZGC, легко понять, почему эта функция не была встроена. Если на вашем хост-компьютере установлены тысячи гигабайт оперативной памяти, вам, скорее всего, не нужно возвращать ее в ОС. Несмотря на это, эта функция была добавлена ​​в ZGC в Java 13, что сделало ее доступной для приложений, которые не всегда работают на специализированных компьютерах корпоративного уровня.

Связанный: вы можете обратиться к основным примерам Java.

Будущие направления

Java 13 — это следующая глава в стремлении сделать Java жизнеспособным функциональным языком. Поскольку Oracle взяла на себя разработку Java, он постепенно превратился в современный язык, способный идти в ногу с самыми горячими тенденциями в разработке приложений. Начиная с Java 8, язык неуклонно развивался в дискретный, легко читаемый, легко расширяемый язык, способный идти в ногу с другими языками, такими как Python, Scala и Kotlin.

На момент написания этого сообщения выпуск Java 14 запланирован на март 2020 года. JEP 352 — единственное дополнение, запланированное для Java 14, но последнее, вероятно, будет включать еще несколько JEP из индекса до конца 2019 года. .