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 года.

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

Как я уже упоминал, вся модель среды ПЛК (которую я разрабатываю) содержится в XML-файле. Этот файл включает в себя список функциональных блоков:

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

Многие пишут, что "бутылочным горлышком" в агентной разработке являются люди, которые проверяют код. Я считаю, что это больше маркетинговое заявление, чем инженерное. Человек может выполнять код-ревью достаточно быстро. Уж точно быстрее, чем код проходит CI/CD пайплайн и деплоится на стенд. С ростом автоматизации, процесс код-ревью человеком сводится к:

- пробежаться глазами по неочевидным местам в коде, проверка которых ещё не покрыта автоматикой,

- проверить как отработала автоматика детерминированной проверки правил разработки.

У меня это занимает не больше 5-15 минут на пулл-реквест. "Бутылочное горлышко" я наблюдаю совсем в другом месте.

Сейчас агенты пишут код очень быстро. Это ускоряет разработку.

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

Казалось бы, может ли что-нибудь пойти не так. Может и обязательно пойдёт не так.

Тестов становится слишком много. За пару лет существования моего проекта люди-программисты написали около 3000 тестов. Половина из них была написана мной в течение года. Я делал много рефакторинга (приводил приложение в порядок), обновлял версии библиотек со сломанной обратной совместимостью и нужно было много тестов как гарантия того, что функционал приложения я не поломал.

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

Казалось бы, пусть первая JVM сохранит результат, а остальные его заберут. Но машинный код JIT зависит от состояния конкретного процесса. От иерархии классов, загруженных реализаций и реального трафика.

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

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

11 ноября в 16:00 МСК на практическом воркшопе Джеймикс (Java-платформа с ИИ для разработки корпоративных систем) встроим ИИ в DMS — систему управления документами.