Java: fill the gaps

Новая фича Java 23: Derived Record

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

Сегодня сяду на любимого конька и расскажу о новом синтаксисе, который появится в java 23 — Derived Record.

Напомню, что records компилируются в final классы с final полями. Неизменяемые переменные — тренд последних лет. В этом подходе данные не меняются, а при модификации создаются новые объекты.

Недостаток очевиден — чтобы создать объект на основе предыдущего, надо написать довольно много кода. Возьмём простой пример — record Point с двумя полями: Х и Y:

record Point(int x, int y) { }
Point p1 = new Point(1,1);

Допустим, нам нужна точка p2, у которой Х в 2 раза больше, чем у p1:

Point p2 = new Point(p1.x()*2, p1.y()); 

Надо прочитать ВСЕ поля исходного объекта и передать их в конструктор с нужными модификациями. Даже в классе с двумя полями надо напрячь глаза, чтобы понять, какой параметр меняется. В реальной жизни полей больше, и получается максимально унылая простыня кода.

Вместо конструктора удобно использовать with методы:

Point p2 = p1.withX(p1.x()*2);

Сразу видно параметр, которым отличаются точки🔥

With методы — отличное решение, но не идеальное.

Возьмём случай, когда между полями должны соблюдаться некоторые соотношения. Например, Х всегда должен быть больше Y.

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

Point p3 = p1.withX(p1.x() - 5);

получаем объект со сломанным инвариантом. Мы не знаем, вызовет ли пользователь потом withY, и не можем это проконтролировать.

Новый JEP работает с такими случаями и предлагает создавать объекты так:

Point p4 = p1 with {
  x *= 2;
  y *= 2;
};

🔸 Названия полей p1 берутся в качестве локальных переменных с теми же именами
🔸 Выполняются преобразования в скобках
🔸 После выполнения блока вызывается канонический конструктор Point, где находится валидация полей
🔸 Полученный объект присваивается объекту p4

В целом всё неплохо, но возникает вопрос целесообразности. На моей практике рекордс обычно используют как контейнер данных, который редко меняется. Если всё же меняется, то обычно это простая логика, куда бы идеально вписались with методы. Если бы records превращались в классы с готовыми with методами — было бы супер удобно.

Я редко встречала в рекордах сложную валидацию и жёсткие отношения между полями. Мне кажется, добавлять новый синтаксис для таких случаев избыточно. Если нужна проверка инвариантов, можно написать свой метод.

Поэтому вердикт новой фиче — сомнительно, но окэй. Я бы потратила человеко-часы на что-нибудь другое🙂 К слову, это уже вторая фича java 23, которая не вызвала у меня восторга. Первой были Gatherers, почитать можно тут

А как вам новый синтаксис в рекордах?
🔥 - огонь, очень полезно
👍 - не вау, но пусть будет
❤️ - просто спасибо за пост:)

5 ошибок при использовании Optional

Optional — супер удобный инструмент, который появился в java 8. В документации его цель явно обозначена — показать, что результат вызова метода может отсутствовать.

Например, функция поиска может найти нужный элемент, а может и не найти. В этой ситуации отлично подойдёт Optional:

Optional<String> search();

С виду всё просто и понятно.

Тем не менее, на практике Optional часто используется некорректно, код получается сложным или плохо читаемым. Самые популярные ошибки:

1️⃣ Использовать Optional во входных параметрах и конструкторах

❌ void init(Optional<String> value) {…}

Приходится добавлять лишние обёртки и проверки.

✅ Лучше проверять параметры на null в начале метода:

void init (String value) {
    if (value == null) …
}

2️⃣ Возвращать Optional при наличии дефолтного значения

❌ return Optional.ofNullable(value).orElse("default");
✅ return value == null ? "default" : value;

3️⃣ Обрабатывать Optional не сразу
и тащить его далеко по коду. Идеально, если обработка происходит сразу после возвращения из метода:

Optiona<String> valueOpt = …
String value = valueOpt.orElse("default");

4️⃣ Возвращать Optional для коллекций

❌ public Optional<List<Integer>> search(…)

Если элементов нет, верните пустой список:

✅ public List<Integer> search(…) {
   … return List.of();
}

5️⃣ Неоптимальная работа с примитивами
Для int, long и double есть специальные классы: OptionalInt, OptionalDouble и OptionalLong.

У них нет затрат на создание объекта, а код становится чуть короче и понятнее. Методов меньше, чем в классическом Optional, но при интенсивной работе с примитивами возможен прирост производительности.

Ответ на вопрос перед постом

Входные параметры лучше проверять внутри метода:

❌ List<Student> search(Optional<String> city)
❌ void init(Optional<String> conf)

Лучше вернуть пустой список, если элементов нет:
❌ Optional<List<Student>> all()

Как считается хэшкод по умолчанию?

На собеседованиях часто обсуждают методы equals и hashcode. За что отвечают, как соотносятся между собой, когда переопределять, а когда не стоит.

Если хочется посмотреть, как думает человек за пределами стандартного ответа, возможен такой диалог:

— Как считается хэшкод по умолчанию?
— Это адрес объекта в памяти
— А почему так?
— Адрес каждого объекта уникален, то что надо для хэшкода
— Сборщик мусора перемещает объекты внутри памяти. Как это влияет на значения хэшей?
— 😥

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

А вот вычисление хэша на основе адреса в памяти — популярный миф. В этом посте разберём, как на самом считается хэшкод под умолчанию.

В разных JVM реализации могут отличаться. Рассмотрим исходный код hashcode в OpenJDK. Там 6(!) стратегий вычисления хэшкода. Стратегия задаётся опциями VM:

-XX:+UnlockExperimentalVMOptions -XX:hashCode={число}

При первом вызове хэш сохраняется внутри объекта и не меняется. Теперь к стратегиям:

🔸-XX:hashCode=0

Случайное число по алгоритму Lehmer RNG. Генератор один на всех, поэтому работает медленно

🔸-XX:hashCode=2

Чемпион по скорости, всегда возвращает 1:

java.lang.Object@1

Используется как отправная точка для тестов остальных стратегий

🔸-XX:hashCode=3

Обычная возрастающая последовательность:

java.lang.Object@a4
java.lang.Object@a5
java.lang.Object@a6

🔸-XX:hashCode=4

Текущий адрес в памяти. Популярный, но неправильный ответ на собеседованиях. Отчасти в этом виновата спецификация: там адрес приводится как пример реализации. Работает быстро, но не даёт равномерного распределения и должного уровня уникальности

🔸-XX:hashCode=1

Адрес объекта в памяти и немного манипуляций с битами

🔸 Стратегия по умолчанию

Случайное число по алгоритму Xorshift RNG. Следующее значение вычисляется на основе предыдущего. Значения равномерно распределены. Работает быстро, тк у каждого потока свой генератор, и синхронизации между потоками нет

Рейтинг стратегий по скорости:
🏆 Вернуть единицу: 184 операций за микросекунду
🥈 Вариант по умолчанию: 176 оп/мск
🥉 Адрес в памяти-1: 160 оп/мск
▪️ Растущая последовательность: 14 оп/мск
▪️ Случайное число и глобальная переменная: 10 оп/мск

Интересно, что до java 8 самая медленная опция была вариантом по умолчанию.

Итого

✅ Реализация хэшкода зависит от JVM и VM-флажков
✅ В OpenJDK 6 стратегий вычисления хэшкода. По умолчанию используется генератор случайных чисел в рамках одного потока
✅ Расчёт на основе адреса памяти не очень хорош по итоговым характеристикам
✅ Общие переменные в методах снижают производительность при интенсивном использовании. Яркие примеры — стратегии хэшкода с общим генератором и последовательностью

👩‍🏫Чему поучиться

Посты это прекрасный, но очень сжатый формат. Для тех, кто хочет большего:

1️⃣ Бот для подготовки к собеседованиям и прокачки навыков

Java, Spring, Kafka, Postgres, микросервисы и всё, что требует рынок от Middle/Senior разработчика

2️⃣ Курс Основы многопоточности

Бесплатный!

Его задача — пройтись по базовым темам многопоточки и заполнить пробелы, если они есть:
▫️ Класс Thread
▫️ Экзекьюторы
▫️ Основные проблемы в многопоточной среде
▫️ Модификатор volatile
▫️ Ключевое слово synchronized

Темы не раскрыты даже на 50%, многие вещи сильно упрощены. Но чтобы понять базу и пройти несложные собеседования — самое то.

3️⃣ Курс Многопоточное программирование на Java

Самый полный и практичный курс по java.util.concurrent и смежным темам🔥

Разбираемся, как писать эффективный и быстрый код и готовимся к собеседованиям. Изучаем best practices и популярные ошибки.

Самая мощная часть — это практика:
✅ Решаем типичные энтерпрайзные задачи
✅ Анализируем многопоточный код Spring, Kafka, Hadoop и других популярных фреймворков — смотрим интересные приёмы и ищем ошибки
✅ Сравниваем разные решения и оцениваем производительность

Такого вы не найдёте нигде. Курс не пересказывает документацию и Concurrency in practice. Он о том, как применять многопоточку в реальной жизни.

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

Если что-то совсем непонятно, можно у меня спросить:)

Что ещё:
▫️ Прохождение занимает 2-3 месяца
▫️ Доступ сразу после оплаты
▫️ Есть рассрочка и оплата за счёт компании
▫️ Можно оформить налоговый вычет и вернуть в следующем году 13% стоимости

Почитать программу, отзывы и записаться → https://fillthegaps.ru/mt

Паттерн Builder для продвинутых

Начав обсуждать билдер, остановиться сложно. Я и не буду:) Сегодня подсвечу пару интересных моментов и один приём, который точно пригодится на практике.

Сразу к делу:

1️⃣ Билдер может содержать сложную логику, а не просто копить будущие поля

Например:
🔸 Собирать одну информацию, отдавать объекту другую
🔸 Возвращать любые классы и объекты, даже прокси и уже созданные
🔸 Проводить операции внутри метода build

Всё это при умелом использовании создаёт симпатичное и лаконичное API.

Пример 1: класс StringBuilder

Гораздо интереснее, чем кажется:
▫️ Копит данные в изменяемом массиве, на выходе отдаёт неизменяемую строку
▫️ Методы append можно вызывать сколько угодно раз
▫️ Есть дополнительные методы вроде reverse или delete

В результате получаем удобный и функциональный класс. Ломбок такой билдер не соберёт, чатЖПТ такое не придумает:)

Пример 2: класс HttpClient

В самом простом варианте код выглядит так:

HttpClient client = HttpClient.newBuilder().build();

🤔 Зачем тут билдер? Почему просто не сделать new HttpClient()?

Потому что внутри build происходит такая магия:

SingleFacadeFactory facadeFactory = new SingleFacadeFactory();
HttpClientImpl impl = new HttpClientImpl(builder, facadeFactory);
impl.start();
…
return facadeFactory.facade;

Тут прячется установка работы с сетью в 200+ строк кода и механизм по завершению работы с сетью, когда объект HttpClient станет не нужен. Хотя объект работает с ресурсами, его не надо помещать в блок try-with-resources.

Мелочь, а приятно🥰

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

2️⃣ Билдер может сделать несколько объектов на базе переданных данных

Часто помогает при написании тестов.

Пример: тестируем работу с классом Account, в котором много полей. Можно в каждом тесте создавать тестовые объекты с нуля и копипастить километр кода. Или поступить иначе:

▫️ Сделать общий для всех тестов билдер, но build() не вызывать
▫️ В каждом тесте доставить нужные поля и построить новый объект

Получается так:

// общее поле c базовой информацией
Account.Builder accBuilder = Account.builder().INN(…).KPP(…)

// в тесте, где важен БИК:
Account acc = accBuilder.RCBIC(123).build();

// в тесте, где нужно название банка
Acccount acc = accBuilder.bankName("green").build();

Это короче, чем в каждом тесте создавать объект с нуля. Плюс сразу видно "главное" для теста поле.

Приём подходит не всегда, но иногда здорово улучшает читаемость.

Итого

✅ Метод build может содержать сложную логику: от проверки параметров до шифрований и преобразований
✅ Builder может создать несколько объектов на основе переданных данных

Возьмите эти свойства на заметку, в умелых руках паттерн Builder делает код проще и удобнее🔥

Что лучше — Fluent API или Builder?

Продолжим разговор о Fluent API и рассмотрим частный случай — создание объекта. Сравним "классический" флуент апи с билдером и посмотрим, когда что использовать.

Вопрос очень актуален, так как не раз приходилось созваниваться и объяснять коллегам это всё словами:) Теперь буду кидать ссылку на пост.

Уточним термины

▫️ Fluent API — это стиль написания кода. Грубо говоря, когда методы соединяются через точку (method chaining). С помощью Fluent API можно создать объект и проинициализировать поля.

▫️ Builder — паттерн для создания объектов, суть которого в постепенном накоплении информации. Билдер тоже использует method chaining и относится к fluent api.

В чём разница на практике?

Допустим, надо создать экземпляр класса Account с информацией о счёте. Рассмотрим 4 варианта:

1️⃣ Все параметры передаём в конструкторе:

Account acc = new Account(111, 222, 333);

✅ Идеально для обязательных параметров. Компилятор не даст шанса пользователю что-то забыть
❌ Плохая читаемость — передаётся набор чисел, непонятно, что есть что
❌ Если есть необязательные параметры, нужно несколько конструкторов

2️⃣ Параметры выставляем через сеттеры:

Account acc = new Account();
acc.setINN(111);
acc.setKPP(222);
acc.setRCBIC(333);

✅ Читаемость лучше. Понятно, с какими полями работаем
❌ Нет контроля за обязательными параметрами. Пользователь должен знать, какие сеттеры вызвать обязательно, а какие нет

3️⃣ Используем Fluent API:

Account acc = Account.new()
    .INN(111)
    .KPP(222)
    .RCBIC(333);

✅ Симпатичнее, чем сеттеры
❌ Та же проблема с обязательными параметрами, никаких проверок
❌ Не подходит для неизменяемых классов
❌ Более сложный код. Но если у вас разрешён ломбок, аннотация @Accessors(chain = true) упрощает задачу

4️⃣ Создание объекта через билдер:

Account acc = Account.builder().
    .INN(111)
    .KPP(222)
    .RCBIC(333)
    .build();

✅ В build() можно добавить нужные проверки
✅ Можно использовать для неизменяемых классов
❌ Надо написать отдельный класс Builder или использовать аннотацию @Builder из ломбока

Создание объекта через Fluent API не очень отличается от билдера по лаконичности, но проигрывает ему в функциональности. Fluent API не может проверить поля на "обязательность".

Итого

🔸 Если в классе мало полей, идём по классическому пути — обязательные параметры помещаем в конструктор, необязательные выставляем сеттерами
🔸 Если полей много или между полями сложные связи — используем билдер. Именованые методы улучшат читаемость, а метод build() проверит всё, что нужно

Fluent API обычно не даёт преимуществ в ситуациях выше, и редко используется для создания объектов. Его сильная сторона — логические блоки из нескольких операций🔥

Fluent API: что такое и зачем нужен

Fluent API набирает популярность последние лет 5 и часто вызывает вопросы:
🤔 В чём его польза?
🤔 Чем он отличается от билдера?
🤔 Когда нужен, а когда нет?

В этом и следующем посте постараюсь ответить на эти вопросы.

Основная задача Fluent API — улучшить читаемость кода. Для этого:

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

Пример:

CompletableFuture.runAsync(…).thenRun(…).exceptionally(…);

Fluent API не всегда уместен и не всегда реализован удачно. Список формальных условий определить сложно, на практике такой формат часто выбирается интуитивно. Поэтому рассмотрим побольше примеров!

✅ Хороший пример из AssertJ:

assertThat(str).startsWith(…).contains(…);

За раз пишем несколько проверок для строки str. Без Fluent API кода будет больше

✅ Хороший пример из Мокито:

when(mock.method()).thenReturn(…).thenReturn(…).thenThrow(…);

Читается как одно предложение. Мне даже сложно представить, как это написать в “традиционном” стиле:)

✅ Прекрасный пример из Spring JDBC:

List<User > users = jdbcClient.sql(…)
.param("rating", 5, Types.INTEGER)
.query(mapper)
.list();

Почему пример прекрасен? Потому что Fluent API скрывает работу с объектом PreparedStatement. Код получается не только короче, но и проще🔥

😐 Так себе пример из Spring Data:

ExampleMatcher matcher = ExampleMatcher.matching()
.withIgnorePaths(…)
.withStringMatcher(StringMatcher.ENDING);

Приставка with у методов лишняя, название последнего метода неудачное

❌ Плохой пример из SLF4J:

logger.atInfo().log(…);

Классический logger.info(…) короче и удобнее

❌ Плохой пример из популярного джава канала:

Person person = new Person().setName(…).setAge(…);

Тоже никакой пользы от Fluent API, ни по читаемости, ни по удобству использования.

Итого

Fluent API подойдёт, когда работа с объектом проходит в несколько шагов, но единым логическим блоком. Основная цель — улучшить читаемость. Высший пилотаж — повысить с помощью Fluent API уровень инкапсуляции.

Чтобы сделать удобно и красиво, нужен опыт, насмотренность и немножко вдохновения:)

Отдельный случай — Fluent API при создании объектов. Здесь часто возникает путаница с билдером, и непонятно, что когда использовать. Этот вопрос я разберу отдельно в следующем посте🔥

Нужно ли высшее образование для разработчика?

Встречаются 2 радикальных мнения:

🧔‍♂️ Вышка не нужна, там старая программа. Всё есть в интернете и можно выучить самому
👩‍🦰 Только с высшим образованием станешь “нормальным” разработчиком, без вышки твой потолок — это круды

Абстрактно рассуждать можно долго, я расскажу свой личный опыт.

Я отучилась в ИТМО на инженера-программиста 11 лет назад. "Информационные технологии" присутствуют в названии универа, факультета и специальности — уровень айтишности максимальный.

Какие плюсы вижу с высоты прожитых лет:

✅ Можно попробовать разные стороны IT

Помимо разработки было море других предметов: кодирование данных, математическое моделирование, ассемблер, компьютерная графика и даже 1С:). Здорово расширяет горизонт и помогает нащупать, что интересно конкретно тебе.

Выбор самоучек ограничен энтерпрайзным меню: фронт, бэк или мобилки. Дальше человек ориентируется на требования рынка.

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

✅ Базовые знания

Как работают операционные системы, компьютерные сети, linux/bash и тд.

На курсах такому не учат, в вакансиях эти требования не прописаны. В итоге часто получаем сотрудника, который боится консоли и не выходит за пределы IDE.

Джунам это простительно — один раз покажешь, как смотреть логи на удалённой машине, и они запомнят. Но чем сеньористее становишься, тем важнее понимание общей картины, и тут пробелы становятся очень заметны.

Эти темы легко освоить самостоятельно, глубокого погружения не требуется. Но на практике редко у кого доходят руки до таких тем. В универе у тебя нет выбора:)

✅ Стажировки, факультативы, конкурсы, хакатоны

от университета и известных компаний. Учёба по обмену в другой стране. Интересные люди приходят читать лекции и делиться опытом.

Во "внешнем мире" тоже полно стажировок, лекций и хакатонов, но для студентов количество программ в разы выше.

А теперь минусы:

❌ Долго и непродуктивно

За 4-5 лет через студента проходит огромный объём информации, и большинство тем он видит в первый и последний раз. Ни ассемблер, ни теория поля мне ни разу не пригодились.

Весь объём знаний, который я использую сейчас, осваивается за полгода-год самостоятельного обучения.

❌ Знаний из университета недостаточно

Нет специальности "Java разработчик". В университете учат на универсального инженера-программиста. Поэтому уходить вглубь пришлось самостоятельно.

В универе рассказывали, что после выпуска нас "будут с руками отрывать топовые компании". Так вот, это неправда. Хотя сейчас во многих универах есть практика с джавой, спрингом и докером, этого недостаточно. Доучиваться всё равно придётся.

Но не всё так страшно. Мне хватило пары месяцев, чтобы подготовиться к собеседованиям и устроиться на работу. После косинусных преобразований и электротехники освоить технологии энтерпрайза очень просто:)

Итого

Хотя мне не пригодилось 90% того, что было в университете, сама учёба мне нравилась, и это было отличное время🥰

🔸 Если вам 15-18, интересно айти и есть время на учебу, рекомендую идти в универ и брать от него максимум. Ходить на факультативы, вписываться в стажировки и доп.программы, наращивать связи

🔸 Если чувствуете серьёзный интерес к области, далёкой от энтерпрайза, поищите соответствующую магистратуру. Разработка языков, биоинформатика, квантовые вычисления, etc — всё это лучше осваивать комплексно и в кругу единомышленников

🔸 Если вы уже работаете и видите, куда и как расти, то получать дополнительно высшее образование не нужно. Полезнее прицельно изучать технологии и качать софт-скиллы

Чего ждать от Java ближайшие 10 лет?

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

⭐️ Project Loom

Цель: добавить легковесные(виртуальные) потоки

Самая заметная фича со времён Stream API. Большинство проектов получат огромный буст от внедрения виртуальных потоков. Что важно — с минимальными изменениями в коде.

В Java 21 вышло базовое апи по работе с виртуальными потоками. Предстоит ещё много работы внутри JVM и в рамках языка, чтобы удобно управлять тысячами задач.

⭐️ ZGC / Shenandoah

Цель: сборщик мусора с минимальными паузами

Сборщики чуть отличаются по реализации, но задача одна — обеспечить минимум простоя во время сборки мусора. Разумеется, не бесплатно. Паузы уменьшаются, но увеличивается расход памяти и снижается пропускная способность.

Для большинства проектов это не актуально. Сборщик по умолчанию G1 отлично работает и становится лучше с каждым релизом.

⭐️ Project Panama

Цель: упростить работу с native кодом и памятью за пределами JVM

Проект делится на 2 направления:

🔹 Новый вариант JNI

Нужен для работы с библиотеками, которые не написаны на Java, и вряд ли когда-нибудь будут: работа с графикой, манипуляции с ОС, сетью и тд. Текущий JNI очень старый, работает медленно и не безопасен. Поэтому пишут новый:)

🔹 Работа с памятью за пределами JVM

Нужна проектам, которые хотят управлять памятью без посредничества Java. Самим делать сборку мусора, сжимать и раскладывать данные по определённым структурам.

⭐️ Project Amber

Цель: упростить язык, добавить новые конструкции

Самые "народные" фичи, которые часто попадают в обзоры и статьи: var, текстовые блоки, records, pattern matching, sealed классы, string templates и так далее.

Что-то получается хорошо, что-то не очень. Где-то много пафосных разговоров про data-oriented programming. Есть странные фичи, вроде упрощения написания Hello world.

⭐️ Project Leyden

Цель: ускорить время старта Java программ

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

⭐️ Project Valhalla

Цель: оптимизировать работу с данными

Здесь так же два направления:

🔹 Создать value types — объект с полями и методами, работа с которым идёт как с примитивом:
✅ Передаётся по значению
✅ Компактно лежит в памяти
✅ Не может быть null

🔹 Создать общую схему работы с примитивами, объектами и value types, избавить разработчика от мыслей про boxing/unboxing

❓ А когда будет готово?

Плохая новость — реализации всех проектов растягиваются на десятки лет.

10 лет — не преувеличение. Лямбда-выражения в java обсуждались с 2004 года, а увидели свет только в 2014.

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

На java пишут большие системы, которые работают десятки лет. Поэтому основательный подход абсолютно оправдан😌

Java 22: изменения в Stream API (с плохим API)

19 марта выйдет Java 22. Там появится интересная превью фича Stream Gatherers. Коротко расскажу, что это, зачем нужно, и что с ней не так.

Начнём. Код со Stream API делится на 3 части:
▫️ источник данных
▫️ промежуточные операции: map, filter, flatMap
▫️ терминальная операция: collect, count, findAny

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

Иногда их недостаточно. Например, хочется сделать distinct по какому-то признаку и дальше работать с исходными объектами:

clients.stream()
.distinct(Client::getBonusType)
.map(Client::getId).forEach(…)

Но это невозможно, distinct работает только по equals. В итоге надо либо извращаться, либо переписывать на for.

В Java 22 в Stream API появится универсальный метод gather. Туда можно передать логику преобразований с любыми отношениями - 1:1, 1:N, N:1, N:N. Синтаксис сложный, но круто, что такая возможность появилась.

Второе нововведение. Для collect есть готовые статические методы в классе Collectors, а для gather появится Gatherers с новыми методами. Самое полезное — два метода по работе с окнами:

🪟 windowFixed — поделить стрим на подмножества заданного размера

[1,2,3,4,5,6] → windowFixed(3) → [1,2,3], [4,5,6]

🪟 windowSliding — подмножества с пересечением одного элемента

[1,2,3,4,5,6,7] → windowSliding(3) → [1,2,3], [3,4,5], [5,6,7]

Что не так c методом gather?

1️⃣ Многословность

Та же ситуация, что и с collect. Чтобы разбить список на окна, придётся написать

list.stream()
.gather(Gatherers.windowFixed(2))
.collect(Collectors.toList())

Даже со статическим импортом выглядит не очень. Хочется писать без лишних слов:

list.stream()
.windowFixed(2)
.toList()

Да, исходный код Stream API сложный, и его тяжело расширять. Да, через статические методы реализация получится проще. Но не вижу ничего невозможного, чтобы сделать новые методы лаконичными, без приставки "gather(Gatherers"

2️⃣ Странные новые методы

Начнём с оконных. windowSliding делает пересечение только по одному элементу. Зачем нужно это ограничение — непонятно. Так же непонятно, зачем делать два отдельных метода windowFixed и windowSliding.

За образец можно взять Kotlin:

list.windowed(5,2)

Первый параметр задаёт размер окна, второй — шаг, с которым идём по списку. Удобно и понятно.

Ещё в Gatherers появятся три странных метода: fold, mapConcurrent и scan. С первого взгляда непонятно, зачем они нужны, очень уж специфичны.

В целом криминала в gather/Gatherers нет, жить можно. Но важный навык разработчика — замечать слабые места в своих и чужих решениях. Этот навык нужно развивать, для этого и нужен этот пост:)

Что ещё почитать:
🔥 Серия постов про коллекторы. Там же я рассказала, почему в стримах используется отдельный метод collect, а не просто toList()
🔥 Новые методы Stream API в Java 16
🔥 Критикую метод HashMap в Java 20. Хотя сам метод маленький, он показывает серьёзную ошибку проектирования API

Best practice: не использовать boolean параметры в методах

На вопрос выше сходу ответят только знатоки многопоточки. Остальные наверняка попытались придумать, что означает cancel(true), и в чём разница с cancel(false).

Метод Future#cancel — наглядная иллюстрация, почему boolean параметры в public методах не ок. Потому что непонятно, что означают true и false.

Public методы определяют интерфейс. В хорошем API пользователю не нужно зарываться в доки, чтобы понять, как пользоваться классом.

Даже если у параметров хорошие имена, итоговые true и false выглядят несимпатично и неудобно.

С private методами ситуация другая. Внутренняя реализация должна быть читаемой и понятной, но требования всё же менее жёсткие, чем у public методов. В private методах флажки допустимы, но увлекаться не стоит:)

Как исправить метод с boolean параметром?

1️⃣ Сделать два метода

и зашить "особенность" флажка в название. Необязательно дублировать реализацию — public методы могут под капотом вызывать private метод с флажком.

Так сделано, например, в классе HashMap для методов put(k,v) и putIfAbsent(k,v). Оба в итоге вызывают private метод putVal с флажком ifAbsent

2️⃣ Создать enum с двумя значениями и передавать его вместо флажка

enum ReplicateStatus {NO_REPLICATION, REPLICATE};
...
saveRequest(req, ReplicateStatus.REPLICATE);

Такой вариант предлагается в книге Effective Java (Item 51).

Выглядит лучше, чем флажки, но на практике такой способ встречается редко. Если enum нужен только для обозначения true/false, быстрее и проще сделать 2 метода с разными именами.

🔥 Ответ на вопрос перед постом — "невозможно определить".

Мы не знаем точно, начала ли задача выполнение до вызова cancel. Даже если задача стартовала, успех cancel зависит от кода внутри задачи. Поэтому итог непредсказуем🤷‍♀️

​Выполнится ли до конца задача, отправленная в экзекьютор? Длительность задачи - около 500мс

От JDBC до Spring Data: часть 2

В этом посте расскажу про популярные модули Spring Data и подскажу важный нюанс при изучении Hibernate.

Spring Data JPA

Hibernate вызвал вау-эффект тем, что взял на себя маппинг и простейшие SQL запросы.

Spring Data JPA пошёл дальше и избавил разработчика от унылых конфигов и возни с сессиями, плюс генерирует более сложные SQL запросы.

Всё очень круто (без шуток), но есть нюанс.

Ванильный Hibernate подразумевает, что пользователь знаком с деталями реализации — умело работает с кэшами 1 и 2 уровня, различает persist/save/merge, использует нужные типы данных и тд.

А вот JPA определяет только интерфейс доступа к данным. Поэтому в Spring Data JPA многие хибернейт фичи не используются.

Пример — ленивая загрузка коллекций и кэш 1 уровня. Spring Data в общем случае при каждом обращении к репозиторию создаёт новую сессию. Кэширования в итоге нет, а при загрузке коллекций ловим эксепшн.

Кэш 2 уровня и EntityGraph поправят ситуацию, но это уже продвинутый уровень:) Недостаточно пользоваться абстракцией "репозиторий", надо знать и Hibernate, и как Spring использует Hibernate.

Практический совет — если что-то читаете по хибернейту, уточняйте, как это работает в Spring Data и работает ли вообще.

Для простых сервисов Spring Data JPA существенно упрощает жизнь. Для сложных тоже, но требует больше знаний.

Spring Data JDBC

— альтернатива Spring Data JPA. Под капотом у него JDBC без посредничества Hibernate.

Интерфейс такой же — пользователь работает с репозиторием и размечает классы аннотациями типа @Id или @Column.

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

Отдельного внимания заслуживает работа с зависимыми сущностями в DDD стиле. А в этом докладе показан наглядный пример и больше различий Spring Data JPA/JDBC.

Важный момент! Не путайте две библиотеки:
🌸 Spring JDBC упрощает работу с соединениями. Запросы, маппинг сущностей, управление транзакциями пишет разработчик
🌹 Spring Data JDBC даёт следующий уровень абстрации — репозиторий. Работа c запросами, маппингом и транзациями упрощается за счёт аннотаций

MyBatis

часто упоминается как альтернатива Hibernate. Называет себя persistence framework, а не ORM, но занимается тем же — помогает писать меньше кода по перегону данных между БД и приложением.

Основное отличие MyBatis от хибернейта — все SQL-запросы пишутся явно, и внутри можно писать if и foreach блоки.

MyBatis в целом ничего, но редко встречается. Причины просты:
❌ Нет Spring Data модуля, только Spring Boot Starter. Писать руками нужно гораздо больше
❌ В MyBatis есть аннотации, но документация и большинство статей используют XML. Выглядит несовременно👨‍🦳

Итого

⭐️ Spring Data * берёт на себя конфиги, работу с сессиями, генерацию некоторых запросов
⭐️ Spring Data JPA упрощает работу с Hibernate
⭐️ Spring Data JDBC предлагает похожий интерфейс, но на основе JDBC
⭐️ MyBatis для тех, кто хочет чего-то другого

Что выбрать?

Функционально Spring Data JPA/JDBC и MyBatis похожи, но со своими нюансами. Адекватных и современных бенчмарков в интернете нет. Статьи вроде "Hibernate vs MyBatis" очень поверхностные, не тратьте на них время.

На практике выбор делается почти случайно. Что затащат в проект на старте, то и используется:)

От JDBC до Spring Data: часть 1

Общение с базой данных связано с огромным количеством технологий — навскидку вспоминаем JDBC, JPA, Hibernate и Spring Data. Они тесно переплетены, и не всегда люди чётко понимают, что есть что и зачем нужно.

В ближайших постах разложу по полочкам основные технологии по работе с данными.

❓Почему всё так сложно? Почему нельзя сохранить всё как есть?

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

Чтобы данные пережили приложение, они записываются в постоянную память. Хранением и организацией данных занимается БД.

В оперативке данные лежат кое-как — где место нашлось, там объект и создаётся. В постоянной памяти данных много, всё упорядочено и оптимизировано. Поэтому модели данных в БД и приложении иногда отличаются.

А ещё БД — это отдельное приложение. В итоге для сохранения/извлечения данных нужна куча дополнительной работы:
🔸 открыть соединение
🔸 составить SQL запрос
🔸 передать в запросе данные из приложения
🔸 преобразовать ответ БД в java объект
🔸 закрыть соединение

JDBC

— стандартные java методы, которые выполняют все пункты выше. Все инструменты по работе с БД под капотом используют как раз JDBC.

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

Spring JDBC

берёт на себя работу с соединениями. Разработчик всё так же составляет запросы, передаёт параметры и преобразует ответы в java объекты.

ORM

Object Relational Mapping — преобразование данных (mapping) из java объектов в сущности БД и обратно.

Формально, ORM — просто название процесса. В случае JDBC весь ОRМ разработчик делает вручную.

На практике под ORM подразумевают ORM библиотеку/фреймворк — какой-нибудь инструмент, который берёт на себя часть работы по запросам и преобразованию данных.

Hibernate

— самая популярная ORM библиотека. Составляет простые SQL запросы и преобразует данные. Упростил жизнь многим и заслужил их любовь❤️

В хибернейте не всё идеально:
▪️ Работа с соединениями (сессиями) остаётся на пользователе
▪️ Для корректной работы надо знать внутрянку (dirty session, как разруливаются отношения и тд).

Сложно не признать, что Hibernate великолепен. Ворвался на олимп ORM библиотек в 2001 году и до сих пор оттуда не слезает🏆

JPA

Сейчас большинство приложений базируются на спринге, но 10-15 лет назад приложения часто опирались на Java ЕЕ. В те года ORM Java ЕЕ выглядел сложно — для каждой сущности требовались несколько классов и кучка интерфейсов.

Hibernate выглядел привлекательно, но нельзя просто взять и добавить библиотеку в проект. Во вселенной Java EE всё работает через спецификации — стандартные интерфейсы.

Поэтому появилась новая спека по ORM — Java Persistence API или JPA. С небольшими отличиями почти полностью списана с хибернейта. Вскоре Hibernate подстроился под JPA и стал использоваться в Java EE.

Итого

⭐️ JDBC — базовое API по работе с БД
⭐️ ORM — преобразование данных между приложением и БД. На практике под “у нас на проекте ORM” имеют в виду, что используется ORM библиотека, например, Hibernate
⭐️ JPA — спецификация по ORM. Набор интерфейсов, аннотаций и описание, как всё должно работать. Не включает в себя конкретную реализацию
⭐️ Hibernate — популярная ORM библиотека, реализующая JPA

В следующем посте распишу вариации Spring Data, и почему материалы по хибернейт могут не соответствовать реальности.