Главное руководство по Java 9

Publisher

Производит предметы для подписчиков для потребления. Единственный метод — subscribe(Subscriber) , цель которого должна быть очевидна.

Subscriber

Подписывается на издателей (обычно только один) для получения элементов (через метод onNext(T) ), сообщений об ошибках ( onError(Throwable) ) или сигнала о том, что больше элементов не следует ожидать ( onComplete() ). Однако, прежде чем что-либо из этого случится, издатель вызывает onSubscription(Subscription) .

Subscription

Связь между одним издателем и одним подписчиком. Подписчик будет использовать его для запроса большего количества элементов ( request(long) ) или для разрыва соединения ( cancel() ).

Поток выглядит следующим образом:

1. Создать Publisher и Subscriber .
2. Подписаться подписчика с помощью Publisher::subscribe .
3. Издатель создает Subscription и вызывает с ее помощью Subscriber::onSubscription чтобы подписчик мог сохранить подписку.
4. В какой-то момент абонент вызывает Subscription::request чтобы запросить несколько элементов.
5. Издатель начинает передавать элементы подписчику, вызывая Subscriber::onNext . Он никогда не опубликует больше, чем запрошенное количество элементов.
6. Издатель может в какой-то момент истощиться или столкнуться с проблемами и вызвать Subscriber::onComplete или Subscriber::onError соответственно.
7. Подписчик может либо продолжать запрашивать больше элементов время от времени, либо прерывать соединение, вызывая Subscription::cancel .

Все это довольно просто, может быть, за исключением Subscription::request . Зачем подписчику это делать? Это реализация обратного давления , механизм, с помощью которого потребители могут сообщать производителям, сколько предметов они могут обработать. Без такого механизма производители могут легко перегружать потребителей, заставляя их отбрасывать товары или иметь неограниченные очереди, в которых хранятся необработанные товары. Ни одно из решений не является стабильным, поэтому при производстве изделий с дроссельной заслонкой было создано обратное давление, если потребители не могут идти в ногу.

Обратите внимание, что JDK предоставляет только интерфейсы и никаких реализаций (за исключением SubmissionPublisher )! Также нет движения к созданию издателей для асинхронных задач, таких как обход файловой системы. Все описанные интерфейсы являются внутренними типами класса Flow , который имеет хорошую вводную документацию . Существует также официальный проект GitHub , который содержит код и подробную спецификацию API . Я создал простой пример , который также может прояснить, что происходит.

Методы коллекционной фабрики

Когда-то была надежда на коллекционные литералы. Разве это не было бы здорово?

 List<String> list = [ "a", "b", "c" ]; Map<String, Integer> map = [ "one" = 1, "two" = 2, "three" = 3 ]; 

Ну, как бы здорово это ни казалось, это нетривиально, и есть веские причины не делать этого. Какая следующая лучшая вещь? Заводские методы! Благодаря JEP 269 мы можем сделать это сейчас:

 List<String> list = List.of("a", "b", "c"); Map<String, Integer> mapImmediate = Map.of( "one", 1, "two", 2, "three", 3); Map<String, Integer> mapEntries = Map.ofEntries( entry("one", 1), entry("two", 2), entry("three", 3)); 

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

Прежде всего, они все неизменны. Правильно, List.of("a").add("b") завершается ошибкой (с UnsupportedOperationException ). Мне нравится: эти фабричные методы часто используются для инициализации полей с набором фиксированных элементов, где изменчивость в большинстве случаев нежелательна. (Если вы слышали, что Java 9 будет содержать неизменяемые коллекции, имейте в виду, что это так. Неизменность не превратилась в систему типов.)

Методы фабрики полностью отклоняют null значения. Независимо от того, как элементы, как ключи, как значения, они запрещены. Хорошо, долой ноль!

Наконец, и это немного безумно, в игре есть рандомизация. Эти коллекции реализованы для максимизации производительности и просто хранят свои элементы в полях (до двух элементов) или массивах фиксированного размера (для большего). Это означает, что их порядок итераций всегда будет одинаковым на всех машинах независимо от hashCode . Это значительно увеличило бы вероятность некоторых частей логики программы непреднамеренно в зависимости от этого порядка.

Чтобы предотвратить это, порядок элемента рандомизируется при каждом запуске программы. При каждом запуске выбирается случайная соль, а затем используется во время этого прогона для размещения элементов в массиве во время построения. Это делает этот процесс детерминированным во время выполнения (так что два вызова Set.of("a", "b", "c") всегда будут иметь одинаковый порядок), но случайным образом при выполнении.

Встроенная интеграция с рабочим столом

Настольные приложения Java всегда торчат как больной палец. Это не изменится в ближайшее время, но JEP 272 делает это немного менее очевидным. Его цель состоит в том, чтобы «[d] определить новый общедоступный API-интерфейс для доступа к функциям рабочего стола для конкретной платформы, таким как взаимодействие с панелью задач или док-станцией, или прослушивание событий системы или приложений». В Linux поддерживается только Unity, поэтому я не смог попробуйте, но код выглядит многообещающе.

Давайте выберем панель задач в качестве примера. Вот некоторые из доступных функций:

• Приложение может запросить внимание, что приведет к отскакиванию или миганию значков панели задач.
• Специфичные для приложения меню могут быть добавлены в контекстное меню значка панели задач.
• Значок на панели задач можно изменить программно.
• Текстовые или числовые значки можно динамически добавлять к значку панели задач.
• Записи панели задач могут отображать индикаторы выполнения и состояния, такие как выключено , приостановлено или содержит ошибку .
• Окна предварительного просмотра могут иметь значки значков.

(Обратите внимание, что не все платформы поддерживают все функции. Удобный метод Taskbar::isSupported позволяет проверить, какие из них доступны.)

 interface ObjectInputFilter { Status checkInput(Class<?> clazz, long size, long nRefs, long depth, long streamBytes); enum Status { UNDECIDED, ALLOWED, REJECTED; } } 

 class EventHandler { volatile boolean eventNotificationReceived; void waitForEventAndHandleIt() { while (!eventNotificationReceived) { /* spinning */ } readAndProcessEvent(); } void readAndProcessEvent() { /* ... */ } } 

 void waitForEventAndHandleIt() { while (!eventNotificationReceived) { Thread.onSpinWait() } readAndProcessEvent(); }