🍃 Spring сдаёт позиции, Hibernate под угрозой, AI-агенты захватывают Россию | Spring АйО Подкаст №26

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS

💬 Аудио версию подкаста можно найти в комментариях

🦥 Аннотация Lazy как спасение от циклических зависимостей

В прошлом посте мы подробно разобрали, как @Lazy помогает экономить ресурсы и ускорять старт приложения. Но забыли упомянуть ещё один крайне полезный кейс применения этой аннотации — борьбу с циклическими зависимостями.

Если в приложении бин A зависит от бина B, а бин B в свою очередь зависит от A — вы получите классическую circular dependency. Spring просто не сможет создать такие бины через конструкторы. Однако, если применить @Lazy на одном из аргументов, Spring обернёт зависимость в прокси и разорвёт цикл.

@Service
public class ServiceA {
    private final ServiceB serviceB;

    public ServiceA(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

Важно: @Lazy здесь влияет только на точку инжекции, а не на весь бин. Оба бина будут инициализированы жадно, но зависимость будет подгружена позже.

Если же вы хотите, чтобы инициализация бина проходила лениво (при первом обращении к бину), то отметьте аннотацией @Lazy и сам бин тоже:

@Lazy
@Service
public class ServiceB {
    // ...
}

⚠️ Использование свойства: spring.main.allow-circular-references=true

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

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

Но будьте осторожны:
– Это работает только с field-based и setter-based инжекцией
– Если используете constructor-based инжекцию, то приложение по прежнему не запустится, лишь немного изменится сообщение в логах
– До Spring Boot 2.6 это поведение было включено по умолчанию — после обновления многие столкнулись с неожиданными фейлами.

Поэтому такой подход стоит рассматривать как временную меру, а не как архитектурное решение.

#SpringTips #Lazy

🧨 Rich Errors в Kotlin 2.4: шаг вперёд или шаг в сторону?

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

fun fetchUser(): User | NetworkError

Такой подход делает потенциальные сбои явными, упрощает тестирование и избавляет от try-catch для предсказуемых ошибок. Новинка уже доступна в Kotlin 2.4 и, по мнению авторов, особенно полезна в бизнес-логике.

Но в сообществе мнения разделились.

✅ Что говорят сторонники Rich Errors?

🛑Это логичное продолжение идеи безопасности типов, как null safety.
🛑Ошибки становятся частью API — теперь явно видно, какие именно проблемы могут возникнуть.
🛑try-catch больше не нужен там, где ошибка — ожидаемый результат.
🛑Тестировать становится проще: вместо моков и исключений — обычная проверка значения.
🛑Хорошо сочетается с функциональными паттернами без необходимости подключать сторонние библиотеки.

⚠️ Что вызывает сомнения?

🛑В контроллерах и сервисах с большим числом потенциальных ошибок сигнатуры методов становятся громоздкими.
🛑Нет способа элегантно агрегировать ошибки: A | B | C работает, но не имеет общей семантики.
🛑В рамках Spring-приложений реалистичная польза ограничена — фреймворки останутся на исключениях.
🛑Добавление такого типа обработки может серьёзно сказаться на времени компиляции.

💭 И что теперь?

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

А вы как думаете? Используете ли Rich Errors в своём коде — или пока просто наблюдаете со стороны?

Ох и жарким же будет обсуждение этой новости в следующем выпуске подкаста Spring АйО 🫣

🗓 Еженедельный дайджест №45

Для тех, кто был слишком занят на неделе или просто пропустил некоторые посты, публикуем дайджест!

🍃 Spring АйО

– JEP 511: Импорт модулей в Java 25 — как упростить работу с библиотеками
– Spring сдаёт позиции, Hibernate под угрозой, AI-агенты захватывают Россию | Spring АйО Подкаст №26
– Аннотация Lazy как спасение от циклических зависимостей
– Rich Errors в Kotlin 2.4: шаг вперёд или шаг в сторону?
– IntelliJ IDEA переходит на единый дистрибутив

⭐️ Партнёры

– Amplicode: День рождения Kotlin уже на следующей неделе!
– JPoint: Алексей Рагозин — Data retrieval на пальцах
– Деплоим Spring Boot приложение через Docker Compose в Timeweb Cloud за 10 минут

😌 @spring_aio

🍃 IntelliJ IDEA переходит на единый дистрибутив, Rich Errors в Kotlin | Spring АйО Подкаст №27

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS

💬 Аудио версию подкаста можно найти в комментариях

👩‍💻 Kotlin празднует день рождения!

Поздравляем всех, кто пишет, учит, продвигает и просто любит Kotlin — язык, который сделал разработку на JVM (и не только!) понятнее, приятнее и современнее. Этот язык программирования был впервые представлен компанией JetBrains 22 июля 2011 года.

С момента первой стабильной версии (1.0) в 2016 году Kotlin прошёл впечатляющий путь:

🛑2017 — Google объявила Kotlin официально поддерживаемым языком для Android
🛑2019 — Kotlin стал preferred language для Android-разработки
🛑2020 — вышел Kotlin 1.4 с улучшенной производительностью и новым тулчейном
🛑2023 — представлена стабильная версия нового компилятора K2
🛑2024 — Kotlin Multiplatform стал стабильным: теперь можно всерьёз писать на Kotlin под Android, iOS, Web и Desktop

Kotlin давно вышел за пределы JetBrains: его используют в крупных продакшн-проектах по всему миру, о нём говорят на конференциях, а комьюнити — одно из самых тёплых и активных.

С днём рождения, Kotlin! 🎂