Spring АйО

🔥 Роман Елизаров про AI в разработке ПО, OpenSource и культуру IT

Большая часть интервью — про практику. Насколько хорошо ИИ-агенты пишут код сегодня, где они реально помогают, а где создают дополнительные риски.

Поговорили о качестве сгенерированного кода, границе ответственности, безопасности, конфликте интересов между разработчиками и безопасниками, а также о монополизации в Open Source.

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

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE

👩‍💻 Почему Kotlin ломает JPA

Используешь Kotlin с Jakarta Persistence и думаешь, что всё работает? Возможно, до первой неожиданной ошибки. data class, val, final-классы и даже значения по умолчанию — всё это может тайно мешать корректной работе JPA.

Вместе с Торбеном Янссеном в новом переводе от команды Spring АйО разберем скрытые ловушки и показывают, как настроить проект правильно, чтобы не наступить на мину.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/987890/

#видеозаписи

Открываем новую видеозапись выступления:
Александр Шустанов — Из Postman в код: Connekt и новый взгляд на тестирование API

😉 YouTube | 📺 VK Видео

🛠️ Observability-as-Code в Spring Boot: Контракты и тесты для метрик, логов и трейсов

Думаешь, метрики и логи — дело вкуса? А вот и нет. В продвинутых командах они становятся частью контракта: что логировать, какие метрики собирать, как проверять всё это тестами и в CI.

В статье от эксперта Spring АйО Евгения Сулейманова рассмотрим, как внедрить наблюдаемость "по-серьезному" — через код, тесты и архитектурные правила. Spring Boot, Micrometer, OpenTelemetry и немного магии ArchUnit.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/987358/

JVM ещё жива, но уже бесполезна: как Netflix научился убивать её по GC

Вместо того чтобы ждать, пока Java-приложение окончательно "зависнет" из-за GC, инженеры Netflix сделали jvmquake — инструмент, который сам определяет, что JVM уже не спасти, вызывает дамп памяти и аккуратно завершает процесс. Меньше тревог, больше аптайма.

Подробности - в новом переводе от команды Spring АйО.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/987116/

🚀 Spring АйО × JPoint: свой трек

В этом году Spring АйО представляет собственный трек на конференции JPoint, Трек будет посвящен разработке на Spring.

Мы открыты к любым идеям, но в первую очередь ищем доклады про Spring и все, что вокруг него:

🟠архитектура и реальные проектные решения
🟠производительность и узкие места
🟠безопасность
🟠тестирование
🟠интеграции и инфраструктура

⚠️ Новое Open Source Решение

Кроме того, на треке Spring АйО состоится первая публичная презентация нового Open Source продукта, посвящённого отладке и глубокому мониторингу приложений на Spring Boot. Автором продукта является один из экспертов Spring АйО сообщества.

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

📩 Заявку на участие можно оставить тут: https://spring-aio.ru/2026

🚨 Срочный апдейт по безопасности в Node.js

Node.js выпустил срочный security-релиз, который закрывает опасную уязвимость отказа в обслуживании (DoS). И это хороший повод обратить внимание всем backend-разработчикам, а не только JS-сообществу.

Михаил Поливаха, эксперт сообщества Spring АйО, пояснил в чём проблема и почему она касается в том числе Java разработчиков.

В чем суть проблемы?

В ряде Node.js-приложений сервер мог падать целиком от одного запроса. Без логов. Без обработки ошибок. Без возможности мониторинга причин.

А всё дело в том, что рантайм Node-ы в рамках ассинхронного контекста (Promise или async/await) не контролировал глубокую или даже бесконечную рекурсию и позволял ей положить весь рантайм.

В результате:

🔵ошибка не перехватывалась кодом
🔵не доходила до глобальных обработчиков
🔵сервер падал с ошибкой

Кого это затронуло сильнее всего?

🔵Приложения на React / Next.js
🔵Любые системы с APM (Datadog, New Relic, OpenTelemetry)
🔵Большинство продакшн-Node.js-сервисов по умолчанию

Что сделали разработчики Node.js?

🔵Исправили поведение: теперь ошибка возвращается в код, а не убивает процесс
🔵Выпустили security-релиз для всех актуальных веток
🔵Отдельно подчеркнули, что это больше смягчение, а не гарантия безопасности

Почему это важно для Spring разработчика?

А потому, что контролировать рекурсию на основе входных данных нужно всегда, и Spring Data, например, в своё время фиксила такую дыру у себя тоже в рамках Property Path Traversal.

Главный вывод

Если глубина рекурсии, размер и строение входных структур или объём ресурсов могут контролироваться пользователем — нужно вводить явные ограничения, как это сделала Spring Data.

Это справедливо для Node.js, для Java / Spring, для любых backend-систем.

📌 Помним, что DoS-уязвимости часто рождаются не в бизнес-логике, а на стыке рантайма, инфраструктуры и удобных абстракций.

🔗 Подробнее: https://nodejs.org/en/blog/vulnerability/january-2026-dos-mitigation-async-hooks

🧪 Project Panama: как Java научилась говорить на C!

Как безопасно и эффективно вызывать C-функции из Java? Благодаря Project Panama — новому API из OpenJDK — это стало возможно без использования JNI.

В новом переводе от команды Spring АйО познакомимся с основами FFM API, посмотрим на запуск Hello World на C, роль jextract, и на то, как управлять памятью вне кучи JVM.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/985144/

🎙 Второй выпуск подкаста «За ширмой IT» уже на канале!

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

— зачем разработчику на самом деле нужен open source
— почему спикерство — это не только про сцену и лайки
— что происходит с рынком и при чем тут AI
— как выбирать технологии и выстраивать обучение, если не хочется бегать за каждым трендом

😉 СМОТРЕТЬ НА YOUTUBE

Приятного просмотра и, как всегда, будем рады вашим мыслям в комментариях 👇

🍃 Дорогие друзья и участники сообщества Spring АйО!

Уходящий год еще раз показал, какую силу имеет профессиональное сообщество. Сегодня Spring АйО — это уже почти 10000 разработчиков, объединенных интересом к Spring, технологиям, обмену опыта и живому диалогу. Ваша вовлеченность, вопросы, комментарии и поддержка делают это пространство по-настоящему ценным.

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

Спасибо, что остаетесь с нами и разделяете этот путь. С новым годом, друзья!🎄✨

⚡️ Spring MCP: набор инструментов для AI-помощника от Amplicode

Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.

Если коротко, в первой статье было несколько основных болей:

• LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только)
• Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало
• Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата
• Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое»

И на этом фоне появляется логичный вопрос:

А можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?

Собственно, Spring MCP от Amplicode про это.

📚 Читать на Хабр: https://habr.com/ru/companies/haulmont/articles/976872/

🛠 Михаил Поливаха. Garbage Collection. Где мы сейчас

Наш эксперт Михаил Поливаха выступил с докладом про сборку мусора:

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

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

😉 СМОТРЕТЬ НА YOUTUBE

🥷 Hidden классы в Java. Что скрывают Lambda выражения

С переходом Java на более безопасные и стандартизированные подходы к динамической генерации классов, скрытые (hidden) классы стали ключевым механизмом замены устаревшего Unsafe::defineAnonymousClass.

Они решают проблемы доступности, управления жизненным циклом и контроля доступа, особенно актуальные для разработчиков фреймворков и языков на JVM. Хотя скрытые классы пока не полностью заменяют функциональность Unsafe, они лежат в основе ряда важных механизмов, такие как, например, реализация лямбд в JDK.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/980928/

🚀 Тред-дампы и Project Loom (виртуальные потоки)

С появлением виртуальных потоков в Java благодаря Project Loom, параллельное программирование стало проще, а производительность — выше.

Однако за этой простотой кроются новые вызовы для инструментов отладки и анализа. Как читать тред-дампы, если их теперь тысячи — или миллионы? Какие средства реально помогают найти взаимные блокировки и аномалии в асинхронном коде? Рассмотрим в новом переводе от команды Spring АйО.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/980566/

Parallel streams — это не «бесплатный» прирост производительности, а дорогая оптимизация.

🟣 Любое распараллеливание добавляет накладные расходы: разбиение данных, управление задачами через fork-join, синхронизацию и объединение результатов. Если операция над элементом дешёвая или данных недостаточно много, этот оверхед полностью съедает потенциальный выигрыш — и последовательный стрим оказывается быстрее.

🟣 Вторая причина — ограничения самой задачи. Многие вычисления по природе последовательны или содержат существенную последовательную часть, которую нельзя распараллелить. Закон Амдала жёстко ограничивает максимальный speedup: даже небольшой последовательный участок ставит потолок ускорению, независимо от количества ядер. В streams эта доля часто больше, чем кажется.

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

Подробнее в новом переводе статьи от Брайана Гоетца – одного из ключевых архитекторов экосистемы Java и главного авторитета по конкурентному и параллельному программированию в JVM.

@spring_aio