Разрыв в неизменяемости: почему Java Records нужны оптики (Lenses)

Records и pattern matching сделали чтение вложенных данных в Java удобным. Но обновить поле глубоко внутри неизменяемой структуры все еще больно: чтобы поменять одну строку (street у адреса менеджера отдела), приходится вручную пересобирать каждый record по пути. В примере это около 25 строк с каскадом копирующих конструкторов и риском ошибки на каждом уровне.

Потенциально новые методы withX() в record помогают мало: обновленное значение все равно нужно протаскивать назад через Address -> Employee -> Department -> Company. Даже JEP 468 (with для records, preview в JDK 25) упрощает один уровень, но не поддерживает вложенное обновление, поэтому получаются цепочки with на каждом слое.

Оптики закрывают этот разрыв: это типобезопасные, компонуемые пути доступа, которые позволяют один раз описать маршрут и дальше читать/писать по нему. Базовая оптика - Lens (ровно 1 цель), есть Prism (0/1 вариант sealed), Affine (0/1 без построения), Traversal (0..many для коллекций). Скомпонованные линзы сами выполняют промежуточную реконструкцию, и обновление превращается в одно простое выражение.

📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/1001066/

❗️Spring АйО на Java Rock Stars meetup ❗️

Друзья, по традиции, эксперты Spring АйО выступят на ближайшем Java Rock Stars meetup.

5 марта. Москва. Лофт Casa Picassa на Бауманской.

💬 В программе:

– Илья и Фёдор Сазоновы расскажут о том, как обычные проекты внезапно начинают задыхаться при масштабировании, хотя пользователей и данных там не так много. Узнаем о причине проблем с производительностью и главном правиле работы с реляционными БД, которое регулярно нарушают.

– Александр Ланцов покажет, как работа со строками и произвольным Unicode в Java может поставить в тупик даже опытного разработчика, и разберёт типичные ошибки на примерах.

Для участия нужна только регистрация.

✈️ Когда использовать параллельный стрим в Java?

parallelStream() не всегда быстрее: в бенчмарке sum(1..100) в параллели занял ~35 476 нс/оп против ~68 нс/оп в последовательном.

Параллельные стримы работают через ForkJoinPool.commonPool (кол-во потоков: ядра CPU - 1). Порядок обработки элементов не фиксирован, а некорректный reduce может дать неверный итог: identity прибавляется в каждом worker`е (например, reduce(5, sum)).

Где параллельные стримы реально полезны:

– Большой объем данных и много вычислений на элемент (так называемая модель NQ: чем больше N*Q, тем выше шанс ускорения; для тривиального суммирования эмпирически N > 10 000).

– Источник легко и равномерно делится: массивы и ArrayList. На 1 000 000 элементов ArrayList в бенчмарке быстрее в параллели (~2.0 мс vs ~5.4 мс).

– Дешевая операция объединения результатов: reduce/sum обычно выигрывают. Например, сумма на ArrayList быстрее в параллели (~2.07 мс vs ~5.51 мс).

– Хорошая локальность данных. Например, массив примитивов (int[]) даёт больший выигрыш, чем массив ссылок (Integer[]), потому что меньше скачков по памяти.

– Есть I/O с большим числом объектов: поиск по 1500 текстовым файлам через Files.walk в параллели быстрее (~10.8 мс vs ~13.3 мс).

📚 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1005180/