Spring АйО

🍃 Spring АйО & Aston ⛔️22 июля встречаемся на онлайн-митапе для Java-разработчиков, который проводим вместе с нашими друзьями из Aston Поговорим о механизмах, которые «вроде бы работают», но требуют точного понимания: Spring AOP, AspectJ, Kafka DLT и архитектуре ИИ-агентов. В программе три практических доклада: ☑️ «Что не так с вашим Spring AOP? Отвечает Axelix» Михаил Поливаха, технический руководитель проекта Axelix Разберемся, как связаны Spring AOP, проксирование и AspectJ и в каких случаях возможностей Spring уже недостаточно. ☑️ «Превратности DLT: как топик ошибок становится кладбищем бизнес-событий» Евгений Сулейманов, технический директор ProzyTech Обсудим, почему Dead Letter Topic без мониторинга и оповещений может привести к потере важных бизнес-событий. ☑️ «Эволюция ИИ-агентов. Как простой запрос превращается в полноценную архитектуру» Максим Александров, старший разработчик программного обеспечения Aston Проследим путь от обычного текстового запроса до полноценной агентной системы с памятью, контекстом, управлением состоянием и планированием. 📅 22 июля, 18:00 по Москве 📍 Онлайн 🎯 Для специалистов любого уровня 🔗 Регистрация по ссылке До встречи на митапе!

❓ Что вам нужно знать про семантику List и Set в Hibernate Казалось бы, ну коллекция и коллекция. Положил List или Set в entity, и живи спокойно. А потом на проде внезапно появляется пачка странных DELETE/INSERT, транзакция тяжелеет, и кто-то обязательно говорит: «Ну это же Hibernate, он такой». Звучит удобно. Только вот удобство это обычно маскирует другое: вы сами сказали ORM одно, а ожидали совсем другое. Использование List и Set для Hibernate это особый сигнал. И от того, какой сигнал вы подали, зависит и SQL, и то, поедет ли у вас Lazy Loading в самый неподходящий момент. Иногда разница выглядит мелкой, но она крайне важна. Если вы хотите не очередной свод правил «делайте так, потому что так принято», а понять, почему ответ именно такой, заходите. Разберёмся без магии и без списания вины на Hibernate. P.S: Данную статью мы написали по мотивам вопросов, возникших у участников Spring АйО Академии. Спасибо всем тем, кто учавствовал в первом потоке! 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1059922/

🍃 Агенты портят архитектуру, IDE не нужна, Spotify не стал лучше | Spring АйО Подкаст №67 😉 СМОТРЕТЬ НА YOUTUBE 😄 Чуть позже... 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

⚡️ OpenIDE Pro теперь доступна всем Java, Kotlin, Go, TypeScript, JavaScript, Python, PHP и встроенный DB-клиент в одном дистрибутиве! Все пользователи OpenIDE могут перейти на OpenIDE Pro без регистрации, без NDA и без каких-либо ограничений. 60 дневный триальный период OpenIDE Pro включает в себя: 1. Полноценную поддержку Spring 2. Расширенную поддержку Go (с отладкой и профилированием) 3. Полный доступ к инструментам для работы с БД (PostgreSQL, MySQL, ClickHouse, Oracle) 4. Поддержку JavaScript/TypeScript вместе с React/Angular/Vue 5. Инструменты для работы с Python и PHP Также доступны бесплатные пилоты для корпоративных клиентов с раширенным триальным периодом. Достаточно просто оставить заявку через форму. Скачать: https://openide.ru/download 📚 Подробнее про OpenIDE Pro читайте в релизной статье на Хабре

🐘 Тестовые фикстуры: управление зависимостями в Gradle В многомодульных Gradle-проектах рано или поздно появляются вспомогательные классы для тестов: фабрики тестовых данных, билдеры, хелперы. Такие классы не относятся ни к продакшн-коду, ни к обычным тестам. Логично было бы переиспользовать их сразу в нескольких модулях, но классическая модель Gradle этого не позволяет: тестовые артефакты одного проекта нельзя просто так подключить как зависимость в другом. На самом деле Gradle умеет решать эту задачу из коробки без вспомогательных проектов и хитрых конфигураций. Начиная с версии 5.6, тестовые фикстуры стали в Gradle полноценной сущностью первого класса, и весь этот пласт боли можно убрать буквально несколькими строчками в build.gradle. Плагин java-test-fixtures заводит в модуле отдельный SourceSet, а другие модули подключают эти классы через лаконичный DSL. При публикации Gradle даже собирает отдельный *-test-fixtures.jar для независимых проектов. В статье на примерах показано, как расшарить тестовые хелперы между модулями, избавиться от дублирования и при этом сохранить чистые архитектурные границы. Если вы устали таскать тестовый код из модуля в модуль, то Вам точно пригодится. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1059130/

🏋️ Масштабирование Java-систем реального времени Событийно-ориентированная архитектура красиво выглядит на схеме — пока не встречается с требованиями реального времени. В статье разбирается опыт масштабирования Java-платформы контакт-центра: почему локальные кеши начали расходиться, как повторное воспроизведение Kafka-событий почти сделало бесполезным автомасштабирование, откуда взялось получасовое отставание потребителей и почему часть критических путей пришлось вернуть к синхронному взаимодействию. Без войны с Kafka и без универсальных рецептов — только архитектурные компромиссы, которые становятся видны под рабочей нагрузкой. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1058484/

🦎 Самокорректирующийся структурированный вывод в Spring AI 2.0 Софту всё чаще приходится интегрироваться с LLM. И тут быстро всплывает неприятная деталь: модели хорошо пишут текст, но не всегда стабильно возвращают данные в строгой структуре. Даже если явно попросить ответ по JSON Schema, модель может добавить пояснение, пропустить поле или вернуть не тот тип. Нативный structured output у части провайдеров есть, но он работает не везде и не одинаково. В статье Кристиан Тцолов, лидер Spring AI, разбирает, как в Spring AI 2.0 решается эта проблема. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1057472/

🤚 Reflection тормозит Сколько раз вы слышали тезис о том, что в Java Reflection тормозит, и лучше его избегать. Насколько это правда? С одной стороны, JMH benchmark на коленке, написанный на Java 17 говорит - деградация по сравнению с прямым вызовом есть, примерно 20-25%. Так в чём же дело? На практике, на performance reflection-а влияет множество вещей: - Проверки на доступ (Известный setAccessible) - Возможности инлайнинга методов JIT-ом - Необходимый Boxing/Unboxing в силу сигнатуры Method#invoke() и т.д. В статье от Бена Эванса, писателя и jvm-инженера, рассказывается о том, почему производительность reflection-а имела проблемы. Однако в Java 18 reflection начал использовать MethodHandles и это многое поменяло. P.S: Если будет интересно, пишите, обязательно расскажем и про MethodHandles. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1056734/

👩‍💻 Spring теперь не тормозит старт приложения из-за тяжелых бинов Одна из старых и вполне понятных особенностей Spring в том, что singleton бины во время ApplicationContext refresh создаются синхронно. Контейнер идет по цепочке последовательно: создал бин, внедрил зависимости, выполнил init-логику, пометил как готовый, пошел дальше. Модель надежная, но дорогая по времени. Если в этой цепочке оказывается бин, который на старте прогревает кеш, тянет данные, готовит внешние ресурсы или делает что-то вычислительно тяжелое, он начинает тормозить не только себя, а весь startup целиком. Даже если этот бин не критичен для первых секунд жизни приложения, контекст все равно вынужден его ждать. 💡 Теперь для таких сценариев, начиная со Spring 6.2 есть background initialization. Можно указать @Bean(bootstrap = Bean.Bootstrap.BACKGROUND), благодаря которой можно пометить конкретный бин так, чтобы Spring инициализировал его в фоне, а основной поток не стоял на месте и продолжал поднимать остальной контекст. Тяжелый бин больше не тормозит весь context refresh. ⚠️ Для инициализации в бекграунде нужен bootstrapExecutor (по-умолчанию, Spring Boot принесёт его самостоятельно). Но тут очень важно понимать, как это работает. Комментарий от Михаила: Работает эта история таким образом - в injection point-ах, где нужен bean, кладётся proxy. Тем самым удовлетворяется зависимость. И вот тут крайне важно - если на этом proxy будет вызов метода, то он будет заблокирован до тех пор, пока реальный ваш bean не инициализируется. В данном случае это похоже на динамику работы Lazy, но не на declaration site-е, а на injection point-е. И ещё вот что важно: даже если вы отдали инициализацию бина в background, Spring Boot не завершит фазу refresh-а до тех пор, пока не встанет этот ваш бин. Это важно, чтобы потенциально сломанное приложение не начало serve-ить трафик. Есть очень хороший доклад от Juergen Hoeller-а, который он давал в Барселоне в 2025г, посмотрите его. У вас прямо много вещей встанет в голове в нужные места. Если подытожить, Spring теперь позволяет не блокировать весь startup на тяжелых, но не критичных бинах, при этом не ломая lifecycle и dependency guarantees.

"IDE больше не нужна. Агенты её убили" — всё чаще слышно из каждого утюга. Может, для людей и правда убили*. А агенты ей пользуются прекрасно, и им нужны ровно те же тулы, которыми раньше пользовались разработчики: поиск по структуре проекта, данные о покрытии тестами, профилировщик. JetBrains проверили это на трёх кейсах: 1. Встроенный поиск IDE вместо grep — минус 13,48% токенов на Kotlin-проекте, качество то же 2. Skill, который находит нужный тестовый файл по данным о покрытии — экономия токенов до 50% 3. Анализ снапшотов dotTrace вместо разбора кода вслепую — точность диагностики выросла с 4,71 до 8,15 из 10, а на сложных багах вроде зависшего UI — с 1,6 до 10 Как считали и что дальше — в статье на Habr: https://habr.com/ru/companies/haulmont/articles/1054434 * P.S. Несмотря на этот тезис, мы всё ещё не знаем ни одного разработчика, который удалил бы IDE с компа. Вот и думайте!