3 эффективных функции Java 9, о которых следует знать медикам

Вам не хватает документации по HTTP-запросам. У вас есть блоки скопированного, но общего кода в интерфейсах. Вы составляете списки, но не знаете, какой из них лучший.

Я написал много кода Java 8. И это были мои главные препятствия. После обновления до Java 11 эти проблемы исчезли .

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

· 1. Convenience factory methods for collections (JEP-269)
  ∘ Problem
  ∘ Research
  ∘ Findings
· 2. Private interface methods (JEP-213)
  ∘ Problem
  ∘ Research
  ∘ Findings
· 3. Carving way for newer HTTP clients (JEP-110)
  ∘ Problem
  ∘ Research
  ∘ Findings
· Takeaway
· References

1. Удобные фабричные методы сбора (JEP-269)

Проблема

Определите библиотечные API, чтобы было удобно создавать экземпляры коллекций и карт с небольшим количеством элементов. Избавьтесь от проблем, связанных с отсутствием литералов-коллекций в языке программирования Java. - источник

В Java 8 нет удобного способа создания небольших коллекций. Хотя есть много библиотек со вспомогательными методами. Что происходит, когда у вас много вариантов? Множество вариантов, выбранных произвольно, приводят к непоследовательной практике кода. Как новые версии Java решают эту проблему? Они добавляют простой, удобный и эффективный способ создания коллекций.

// new way to create collections
Set<String> set = Set.of("a", "b", "c");

Другая проблема. Многословие. Добавление элементов в коллекцию происходит с высокой степенью детализации. Больше подробностей - больше шаблонного кода. Как Java 9 снижает уровень детализации? Java 9 предоставляет простые методы создания коллекций. До Java 9 было много шаблонов для создания простой коллекции.

Вот исследования и результаты тестов производительности.

Исследовательская работа

Вот мое дополнение к JEP-269. Мы воспользуемся этим тестом и увидим, что JEP-269 ускоряет обработку небольших коллекций.

В чем суть теста? У вас есть несколько способов создания коллекций. Если у вас есть простая модель Cat, вам нужно добавить их в catsNonJava9Way. Создайте экземпляр каждого и добавьте их в цикл. Когда модели простые, содержащие одну строку, вы можете удалить экземпляры. Это catsJava8Way. catsJava9Way показывает новый способ Java.

Вот как новая версия Java улучшает небольшие коллекции.

Пропускная способность лучше с подходом Java 9. Нет создания временных объектов. То же самое происходит и в среднем по времени.

Что тормозит предыдущие подходы Java? Размещение временного объекта. Две трети времени уходит на создание объекта. Удаление переменной new Cat ускоряет выполнение. Избегайте использования временных переменных. На их выделение, сборку мусора и назначение требуется время.

Брайан Гетц предполагает, что подход Java 8 приносит больше вреда, чем пользы. Вредит читабельности кода, пропускной способности, но не в среднем по времени.

Проведем сравнение. После тестов среднее время Java 9 не превосходит подход Java 8. Среднее время незначительно, поскольку оно в несколько раз меньше.

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

Каков вывод? Выбирать Java 9 или Java 8 по производительности не имеет смысла. Они оба неплохо выступают. Вы должны выбрать то, что делает код чище. Выбор за вами.

cats8 = Collections.unmodifiableList(Stream.of("George", "John", "Mack", "Other", "Lorem").collect(Collectors.toList()));
// or this one
cats9 = List.of("George", "John", "Mack", "Other", "Lorem");

IntelliJ по умолчанию предлагает более чистый способ. Более чистый способ создания коллекций.

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

JEP-269 не предназначен для больших коллекций. Это не цель. Вот эталон, который я использую, чтобы доказать это.

Java 8 работает лучше, чем Java 9, с большими коллекциями.

Результаты

Java 9 дает ясный, краткий и эффективный способ создания коллекций. Все используют один и тот же API, например, List.of, что упрощает использование. По моим оценкам, это ускоряет создание коллекции порядка сотни раз.

Большие коллекции лучше работают с Java 8. Целью этого изменения не было улучшение обработки больших коллекций. После бенчмаркинга мы видим, что не цели достигнуты. Обработка больших коллекций не улучшается.

2. Методы частного интерфейса (JEP-213)

Проблема

Использование методов копирования и вставки в интерфейсе. Подобный код копируется снова и снова. Используя частные методы, вы можете поместить общий код в частный метод.

Project Coin добавил незначительные улучшения в Java 7. Теперь он включен в LTS Java. Посетите JEP-213, чтобы узнать больше о проекте Coin.

Исследовательская работа

Java 9 работает лучше. Теперь у нас есть две причины использовать частные методы:

  • представление
  • читаемость кода

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

Почему вызывает повышение производительности? Мое скромное мнение - частный метод становится горячим. Вот эталонные результаты.

Результаты

Использование методов частного интерфейса создает лаконичные интерфейсы. Копирование одного и того же кода невозможно. Частные методы, содержащие общий код, сокращают количество строк кода.

Еще одно преимущество частных методов - производительность. Пропускная способность и среднее время лучше в подходе Java 9. Приватный метод становится «популярным» и в среднем работает лучше.

3. Способ резерва для новых HTTP-клиентов (JEP-110)

Проблема

Брайан Гетц предполагает, что старые HTTP-запросы закончились. JDK 1.1 сначала добавляет поддержку HTTP-запросов. Вплоть до JDK 9 вы могли использовать устаревшие Gopher и FTP. Без Java 9 клиент HTTP неэффективен, так как он содержит множество устаревших функций.

До Java 9 запросы HTTP не поддерживали HTTP / 2. В будущих версиях Java HTTPClient станет де-факто HTTP-клиентом в Java.

Старые собственные клиенты были медленными, трудными в использовании и не имели документации. Вы все еще можете найти активные вопросы StackOverflow о HTTP-запросах. JEP-110 открывает путь к лучшему HTTPClient.

Исследовательская работа

Вот как вы могли бы использовать новый класс HTTPUrlConnection.

Вот новый подход к инкубатору HTTPClient. В настоящее время инкубированный HTTPClient входит в состав java.net.http.

Мы можем еще раз проверить этот вопрос. Выделяется Один ответ. Это способ HTTP в Java 9. Сравним принятый ответ и этот. Подход Java 9 позволяет добиться большего с меньшим количеством кода.

Для HTTPUrlConnection нет асинхронности. Вам нужно взломать, чтобы получить асинхронность. В новом HTTPClient это встроено.

Результаты

HTTPClient - это новый способ выполнения HTTP-запросов. Поддерживает новый протокол HTTP, создает краткий код и актуален.

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

Забрать

Более новая Java предлагает новые удобные методы для создания коллекций. Основное внимание уделяется коллекциям меньшего размера, как вы можете видеть в наших тестах производительности. Использование статических фабричных методов Java 9 снижает многословие и повышает производительность.

Методы частного интерфейса положительно влияют на наши интерфейсы. Теперь вы можете извлечь общий код и повторно использовать его. Это дает повышение производительности, поскольку компилятор предпочитает небольшие общие методы.

Брайан Гетц одобряет новый HTTPClient. Это открывает путь для асинхронных запросов. Поддержка более новых версий HTTP. В конце концов, лучший опыт разработчика.

Даже после этих изменений большинство людей используют Java 8. Вам следует перейти на Java 11, поскольку она также поддерживает LTS. Не только LTS, но и все функции, которые вы видели в этой статье.

использованная литература

Освоение Java 9 - доктор Эдвард Лавьери, Питер Верхас