Java *

Почему я начал делать эту штуку? От жадности и от лени.

Нам начали упорно на работе пропихивать модную игрушку (чтобы мы же её и оплачивали). Ну, как бы, не трудно было заметить, что эта драная обёртка в 10 раз больше цены, чем те модели искусственного интеллекта, которые там реально работают. Ну и к тому же интерфейс с вырвиглазной цветовой схемой не для моего зрения. Главное, конечно, от жадности — не хочется оплачивать «воздух» наглым халявщикам, — чувствуешь себя лохом.

Когда я пришёл в проект, меня встретил Java-монолит: около 2000 классов, 120 тысяч строк кода и очень много сложной бизнес-логики. Его шесть лет писала команда из двух–пяти человек, и, судя по коду, о понятии технического долга никто в компании не слышал.

Примерно за полгода до моего прихода команда начала работать с Copilot, а потом перешла на Claude Code. Тесты в проекте появились только вместе с Claude, но их было мало. Позже выяснилось, что и те толком ничего не проверяли.

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

Я написал transactional outbox для двух своих коммерческих проектов. Подходящих готовых решений на момент написания не было, а CDC на основе лога с Debezium показался слишком тяжёлым для простого требования: сохранить событие вместе с данными и отправить его позже. 

Само требование появляется потому, что сервис, который меняет базу и затем публикует сообщение, пишет в две системы, а транзакция базы данных покрывает только одну из них. Если процесс умирает между коммитом и публикацией, данные изменились, а никто об этом не узнал. Поменяйте порядок местами - и сообщение уйдёт об изменении, которого не случилось.

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

Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix.

Представьте довольно простую ситуацию. У Вас есть Spring Boot сервис, который раз в некоторое время ходит во внешнюю систему и синхронизирует какие-то данные. Обычный метод с @Scheduled, ничего особенного. И вот к Вам приходит коллега и говорит:

Что-то часть данных не обновилась. У нас точно синк прошёл?

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

Если вы хотя бы какое-то время писали код в Enterprise, то я уверен, что для вас это знакомая история. И к сожалению, часто для большинства команд поведение этих самых Scheduled тасок на проде или на тестовом окружении покрыто туманом войны, там до конца непонятно, что происходит.

Недавно мы срелизили Axelix 1.3 и одна из фич, которую мы сделали, это добавили историю выполнения scheduled tasks

Тезис: Как мы автоматизировали подготовку релизов в банке (Java 17, Spring), написали свой плагин для проверки release notes и обошлись без выделенного DevOps-инженера, используя чистый Java-стек в закрытом контуре.

Spring Security обладает интересным свойством: подключить его к проекту очень просто, а вот понять, что именно произошло после добавления зависимости, уже не так просто.

Вот вы добавили spring-boot-starter-security, и приложение внезапно начало возвращать форму входа. Откуда взялся пользователь? Кто создал цепочку фильтров? Почему один запрос завершается со статусом 401, а другой со статусом 403? Почему после добавления еще одного SecurityFilterChain часть прежних правил будто бы перестала работать?

Можно, конечно, каждый раз находить похожий пример и копировать конфигурацию. Иногда это даже будет работать. Проблема начинается тогда, когда поведение фреймворка нужно изменить или когда найденный пример относится к другой версии Spring Security.

Главная проблема большинства материалов по Spring Security в том, что они показывают какую-то небольшую часть общей картины, при этом у человека после чтения не остается цельная модель происходящего.

С этой точки зрения предлагаю посмотреть на четвертое издание книги Бадра Насслахсена «Spring Security». Русское издание вышло в 2026 году. Это будет небольшая рецензия/обзор книги с моей стороны.

Сразу обозначу свою позицию. Я не считаю эту книгу универсальным руководством по безопасности приложений и не думаю, что ее примеры можно бездумно переносить в production. Но как способ систематизировать знания именно по Spring Security она вполне заслуживает внимания. Ниже постараюсь объяснить почему.

Вдвое урезали память контейнеру. Тесты прошли. На реальном трафике тоже все отлично. Две недели всё работало стабильно.

Но затем почему-то нагрузка изменилась, и больше 60% запусков пришлось повторять с увеличенными ресурсами.

Так ребята из Netflix получили классный урок при разработке системы, которая сама подбирает ресурсы контейнеров. Оставить всё с запасом выходит дорого. Убрать запас страшновато. Особенно когда контейнеров сотни тысяч в день, а менять настройки будет не человек.

OpenRewrite обновил зависимости, поправил код, тесты прошли — кажется, миграцию на Spring Boot 4 можно считать успешной. Но что, если после такого обновления старые клиенты начнут получать 400, а привычные значения в JSON внезапно изменятся? На примере сервиса заказов разберём, откуда берутся эти расхождения и как поймать их до выката с помощью снимков API‑контракта.

Как обновлять технологический стек в большом проекте, автоматизировать разработку с помощью AI-агентов и находить решения для задач, с которыми не справляются готовые инструменты?

Эти темы разобрали эксперты ЮMoney и Сбера на Java Jam — митапе ЮMoney о Java-разработке и не только. Делимся тремя основными мыслями и записью докладов.

Привет, Хабр. У меня дома уже много лет лежит iRobot Roomba — та самая, из середины нулевых. Выкидывать жалко, работать как пылесос она уже толком не хочет, а тут я вспомнил про старый проект HackingRoomba Тода Курта: он ещё в 2006-м показал, что Roomba можно заставить играть мелодии через открытый протокол Roomba Open Interface. Идея была классная, но утилиты RoombaMidi и RoombaMidi2 давно перестали запускаться на современных ОС — драйверов нет, порты другие, Java несовместимая. В общем, всё умерло, кроме самих роботов.

Вот я и решил: а почему бы не написать своё приложение, которое будет работать на нормальном современном ПК? Так появился RoombaMusic. О том, как я до этого дошёл, что сломалось по дороге и почему в итоге всё-таки заиграло — ниже.

В контроллере Flux, приложение на WebFlux, всё выглядит реактивно. А под капотом файл сначала целиком оседает во временном хранилище. Десять загрузок по 2 ГБ и можно идти выяснять, кто съел диск.

Ловушка прячется в привычном @RequestPart. Одного реактивного типа недостаточно, чтобы байты обрабатывались по мере поступления.

В статье показываем, как устроить настоящую потоковую загрузку через Flux<PartEvent>. И проверяем её файлом на 512 МБ при куче 256 МБ.

Октябрь стал для GigaIDE месяцем больших изменений: вышел единый дистрибутив 2026.1, в бесплатном Community-режиме появились C# и Go, а привычные инструменты для Java/Kotlin, JavaScript/TypeScript, Python, баз данных и интеграций получили новые возможности. Собрали главное за месяц — от новых языков до доработок плагинов.

Release notes за предыдущий месяц доступен по ссылке.

Я делаю Telegram‑бота, который пересылает новые письма из почты в чат. Главное требование — скорость: если письмо приходит через минуту, проще открыть почту самому. С Mail.ru и Яндексом все заработало сразу, а Gmail присылал уведомления о новых письмах с опозданием до 44 секунд.

В статье расскажу, как я искал причину, почему первое рабочее решение оказалось опасным (240 входов в почту в час на каждый ящик) и чем все закончилось: одно постоянное соединение и около 8 секунд от отправки письма до уведомления в Telegram. В конце — еще несколько грабель IMAP, которые не описаны в туториалах.

Стек: Kotlin, корутины, Jakarta Mail (реализация Eclipse Angus), Ktor, SQLite, Docker Compose. Все замеры — на сервере с 1 ГБ памяти, по логам бота: это наблюдения на нескольких ящиках, а не строгий бенчмарк.

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

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

В этом дайджесте Сбера — три инструмента, которые наши инженеры создали для практических задач и открывают для внешних команд: HG SDLC, Spring AI GigaChat и Schedulex. Разберём, где они могут пригодиться, как устроены и что учесть перед использованием.

Как сохранить контекст между этапами разработки с ИИ-агентами?
Как встроить GigaChat в Java-приложение?
Как связать фоновую задачу с бизнес-транзакцией и восстановить работу после перезапуска?

Каждое из решений отвечает на один из этих вопросов. Поехали!

В JDK 27 продолжается планомерная работа над производительностью всех компонентов JDK. После выхода JDK 26 в проект OpenJDK внесли более 2300 коммитов, включая изменения в библиотеках, сборщиках мусора, JIT-компиляторе и среде исполнения.

Одно из изменений затронет особенно широкий круг приложений: компактные заголовки объектов (Compact Object Headers) теперь включены по умолчанию. Среди других изменений — использование G1 в качестве сборщика мусора по умолчанию во всех окружениях.

Всем привет!

Меня зовут Михаил Поливаха, я технический лидер проекта Axelix. Недавно мы перешагнули отметку 10 000 загрузок в месяц. Мы сами разрабатываем инструмент для работы со Spring-приложениями, поэтому вопросы релизных циклов, поддержки версий и обновления зависимостей для меня не абстрактная теория. С ними приходится сталкиваться и в роли пользователя Spring, и в роли разработчика Open Source-проекта.

А начать я хочу с ситуации, которая, я думаю, знакома многим. Релиз уже в плане, фича написана, тесты зелёные, сборка собрана. Осталось прогнать последний пайплайн и выкатить изменения. И вот на шаге SCA всё становится красным: в одной из зависимостей нашли уязвимость.

Ну ладно, бывает. Сейчас поднимем patch-версию, заберём исправление и поедем дальше. Для того patch-релизы и существуют, верно?

Открываете Maven Central, смотрите на свою линию Spring Boot, а следующего номера там нет. И, что гораздо хуже, уже не будет.

Допустим, у Вас Spring Boot 3.5.16. Это последний открытый релиз линии 3.5, он вышел 25 июня 2026 года. Следующий номер, 3.5.17, в календаре Spring есть, но помечен как enterprise. То есть патч существует. Проблема в том, что Ваш пайплайн смотрит на Maven Central, а туда этот патч не попадёт.

В этот момент почти обязательно находится коллега, который говорит: «Так 3.5 же LTS! Как это патча не будет?»

Под капотом Spring WebFlux: Event Loop, block() и почему ThreadLocal вас подведет

У нас в «Синимекс» периодически вспыхивал внутренний холивар: кто-то из команды регулярно приходил с идеей «давайте переведем все на WebFlux, это же современно», а кто-то не менее регулярно отвечал «зачем, MVC справляется». Спор ходил по кругу, пока мы не решили заменить ощущения цифрами: провели внутренний бенчмарк, собрали результаты в методичку, а заодно складывали в копилку ловушки, в которые попадали джуны (и не только) при переезде на реактивщину. 

В этой, 2-й части, разбираю четыре фактора, которые чаще всего превращают реактивное приложение в блокирующий кошмар — block() внутри пайплайна; молча теряющийся ThreadLocal; контекст, который нужно правильно пробросить, и легаси-код, который нельзя просто выбросить.

Всем привет! 👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

Октябрь выдался насыщенным: JDK 28 обрастает новыми возможностями, Project Leyden готовит AOT-компиляцию, ZGC учится эффективнее управлять памятью, а работу с off-heap памятью ускорили аж до 18 раз. Тем временем Spring AI обзавелся полноценной памятью сессий и подтверждением вызовов инструментов, а Quarkus представил инструмент для упрощения миграций между версиями. Разбираемся, что происходит внутри JVM, какие новинки стоит взять на заметку и чем еще порадовала Java-экосистема за прошедший месяц. Поехали! 🚀

Состоялся релиз открытого кроссплатформенного проекта для работы с файлами в формате PDF (разделение, слияния, извлечения страниц, смешивание и поворот) под названием PDFsam (PDF Split And Merge) 6.0.9. Исходный код решения написан на Java и опубликован на GitHub под лицензией GNU Affero General Public License v3.0. Сборку PDFsam 6.0.0 представили в апреле 2026 года. Версия проекта PDFsam 5.0.0 вышла в январе 2023 года. Проект PDFsam 4.0.0 представили в декабре 2018 года. Релиз PDFsam 3.0.0 случился в ноябре 2015 года.