Spring АйО

🔥 ORM снова в огне: почему “Вьетнам индустрии” никуда не делся — и при чём тут Spring Data JDBC

Во время подготовки к Spring Data JDBC Event, эксперт нашего сообщества, Михаил Поливаха, вновь поднял тему, которая болит у индустрии уже больше двух десятилетий. Поводом стала знаменитая статья Джеффа Отвуда (основанная на мыслях Теда Ньюарда) — та самая, где прозвучала фраза

«ORM — это Вьетнам нашей индустрии»

И что самое интересное: в 2025 году она звучит не менее актуально, чем в 2004-м.

Корневая проблема всё та же: объектная модель и реляционная модель — два мира, которые не хотят мириться друг с другом. ORM обещает стать «мостом», но чаще оказывается болотом компромиссов, где всё работает… пока не перестаёт.

Джефф перечислил 6 путей, которыми индустрия пыталась сбежать от этого несоответствия:

1. Выбросить объекты. Забить на rich-domain подход и возвращать проекции/tuple’ы. Нет объектов ⇒ нет mismatch’а. Практично, как бы цинично это ни звучало.

2. Перейти к "объектным" хранилищам. OODBMS вроде db4o пытались хранить объекты как есть. Идея жила недолго, но как попытка — эпохальная.

3. Писать маппинг руками. JDBC/JOOQ и полный контроль. Иногда это даже предпочтительнее: больно, но честно.

4. Принять ограничения ORM. Hibernate-путь: 70–80% задач закрываем ORM, остальное — raw SQL. Звучит разумно, если не забывать про кэш и согласованность.

5. Встроить реляционность в язык. LINQ, Scala, F#. Красиво, но массовым это так и не стало.

6. Сделать сами объекты реляционными. RowSet/DataSet-подходы. Интересная идея, но нишевая.

В финале Джефф говорит жёстко, но честно: уберите O или уберите R из ORM — и проблема исчезнет.

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

⚡️ JSpecify пришёл в экосистему Java по-настоящему

В новой версии IntelliJ IDEA JSpecify теперь будет автоматически подтягиваться через зависимости: Spring Boot 4, Spring Framework 7, JUnit 6, Guava 33.4+.

Звучит классно, но на этапе тестирования фичи разработчики быстро упёрлись в некоторые проблемы. Стоило добавить @NullMarked, как IDE начинала закидывать сотнями предупреждений, причём даже в проектах, которые проходили NullAway на CI абсолютно чисто.

Причина проста – спецификация намеренно оставляла свободу в интерпретации опредлённых сценариев в коде, что приводило к разногласиям между инструментами, например, между IntelliJ как IDE, и NullAway как CI инструмента.

В итоге JSpecify рисковал превратиться в ещё одну спецификацию наряду с JSR 305.

JetBrains, Spring и команда NullAway провернули следующее: сели, разобрали кейсы, устаканили своё понимание спецификации и пришли к единому результату в IntelliJ IDEA 2025.3 и в NullAway:

🟣 Предупреждения IDE теперь совпадают с NullAway в тех же сценариях
🟣 Cмешанные аннотации мигрируются намного мягче
🟣 Suppressions стали переносимыми

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

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

⚡️ AOT-репозитории в Spring Data теперь доступны сразу в четырёх модулях

После почти полугода полировки Spring официально включили Ahead-of-Time репозитории в релизе 2025.1.0. Теперь AOT работает не только для JPA и MongoDB, но и для Cassandra и JDBC — и генерирует полноценный код репозиториев ещё на этапе сборки.

Главная фича — репозиторий больше не чёрный ящик. Генератор создаёт читаемый Java-код и JSON-метаданные, так что можно спокойно ставить брейкпоинты, видеть реальные запросы и понимать, что именно делает Spring Data. Для JPA, JDBC и Cassandra генерируется разный код — максимально близкий к конкретной технологии.

Плюс, AOT отлично дружит с новыми возможностями Java: репозитории и вспомогательный байткод могут попасть в AOT Cache и загружаться как готовые классы из shared objects. Это даёт ощутимый прирост времени старта и снижает потребление памяти.

Есть и нюансы: часть конфигурации «замораживается» (например, JdbcDialect нельзя динамически менять), сборка становится тяжелее, а reactive-репозитории пока не поддерживаются.

Но если вы хотите сервисы, которые стартуют быстрее, удобную отладку и меньше скрытой магии — AOT-репозитории выглядят как одно из самых интересных обновлений Spring Data за последние годы.

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

@spring_aio

🤩 Прямой эфир про Spring Data JDBC с Михаилом Поливахой

Онлайн, 9 декабря в 17:00 (МСК) команда Amplicode совместно со Spring АйО проведёт митап про Spring Data JDBC!

В программе:
– Как правильно строить и использовать агрегаты в Spring Data JDBC.
– Почему API устроено так, как устроено — взгляд изнутри от участника разработки Spring Data.
– Фильтрация данных, удобные DTO, реализация бизнес-операций.

Участие бесплатное. Обязательно зарегистрируйтесь, чтобы не пропустить.

🔗 https://events.amplicode.ru/spring-data-jdbc

🪨 Spring Framework получит нативную поддержку Python и JavaScript

Михаил Поливаха, эксперт сообщества Spring АйО и контрибьютор в Spring, поделился своими мыслями по поводу issue под номером 35725, который на первый взгляд может показаться неоднозначным.

В версии Spring Framework 7.1 (предположительно) появится возможность нативно исполнять Python, JavaScript и другие scripting-языки — благодаря интеграции с GraalPy, GraalJS и Truffle. Почему это вообще стало возможным?

GraalVM переживает перестройку: Oracle выводит проект из жёсткой привязки к Java SE, переосмысляет приоритеты и активнее ищет рынки для GraalJS/GraalPy. Эти направления продолжают активно развиваться — и как раз становятся фундаментом для будущей поддержки скриптов в Spring.

Важно: Spring и GraalVM исторически «дружат» ещё со времён Spring Native. Graal часто использует Spring Petclinic в своих демо, а Spring — один из ключевых потребителей AOT-технологий, Leyden и связанных инициатив. Поэтому усиление интеграции — логичный шаг.

Что это даст Spring?
— возможность встраивать скриптовые плагины, DSL и расширения без JVM-обвязки
— шанс усилить позицию в экосистеме AOT/fast startup
— поддержку Graal-линейки продуктов, что укрепляет союз с Oracle

Но стоит понимать и риски: новый API будет нишевым, а неаккуратное использование может легко привести к провалам в части security. Потому массовым решением это вряд ли станет.

Одним из драйверов всей инициативы считается Sébastien Deleuze — лидер Spring Framework, ранее создатель Spring Native и большой энтузиаст Kotlin и Graal. Многие в комьюнити отмечают, что благодаря его видению удалось «подтянуть» Spring к новой AOT-эпохе.

P.S. Эксперт сообщества Евгений Сулейманов отметил, что по его мнению ставка Spring на GraalVM — это не «хайп», а игра в долгую. Если Oracle найдёт устойчивые продуктовые ниши для GraalVM, Spring почти гарантированно станет дефолтным enterprise-фреймворком для полиглот-платформ нового поколения. Важно учитывать это, если вы планируете архитектуру на горизонте 5–7 лет.

@spring_aio

🔥 Бесплатный оффлайн митап в МСК

На предстоящем Java Rock Stars Meetup для вас выступят две легенды из мира Java:

🟣 Роман Елизаров с докладом "От языков программирования к Developer Experience"
🟣 Алексей Рагозин с докладом "JDK Flight Recorder в Java 25"

Участие абсолютно бесплатное. Главное – зарегистрироваться!

P.S. Как классно было в прошлый раз можете оценить по прикрепленному шортсу)

😎 Перестаньте думать и начните уже писать код!

Джефф Атвуд говорит вслух то, что многие думают, но редко признают. Можно часами гонять UML и вылизывать диаграммы, но без живого прототипа все эти решения — чистая фантазия на тему «как бы оно выглядело, если бы существовало».

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

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

⚡️ Вышел Spring Boot 4

Spring Boot перешёл на новую мажорную версию — 4.0.0. Релиз состоялся 20 ноября 2025 года, его анонсировал Phil Webb от имени всей команды Spring. Новая версия построена на Spring Framework 7-ой версии.

Михаил Поливаха также выложил небольшую статью на Habr, где описал мотивацию за главным структурным изменением Spring Boot 4 - разбиением Spring Boot на модули.

Главное:
• Полная модульность: кодовая база переразбита на меньшие и точечно используемые JAR'ы.
• Null safety благодаря JSpecify: везде, по всем проектам Spring.
• Поддержка Java 25 (и сохранена совместимость с Java 17).
• API Versioning: встроенные средства управления версиями REST-API.
• HTTP Service Clients: новый стандартный способ описывать REST-клиентов.

Команда Spring предоставила отдельное руководство по миграции.

Материалы от сообщества Spring АйО на тему Spring 7 и Spring Boot 4:
• Нативный API Versioning в Spring 7: долгожданная официальная поддержка
• Jackson 3 ворвался в Spring
• Состояние HTTP-клиентов в Spring
• Spring Boot 4 и Spring Framework 7: Ключевые фичи и изменения
• Вышел Spring Framework 7.0

🍃 @spring_aio

🤖 Мечтают ли ИИ-агенты об удобных IDE?

О программировании с помощью AI-агентов трубят из-за каждого угла. Последнее время появилось достаточно много инструментов, которые буквально пишут код за разработчика.

Наша команда следит за индустрией ИИ в разработке достаточно давно. Помимо внедрения ИИ в сам процесс разработки наших продуктов, мы активно занимаемся интеграцией Amplicode с современными AI-агентами и не только.

И у нас есть свои мысли на этот счет)

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

🔥 В Spring 7 завезли нативное версионирование API

База нововведения — ApiVersionStrategy. Он понимает, где искать версию (header, query, media type или путь), умеет её парсить как семантическую, знает поддерживаемый диапазон и может автоматически выставлять Deprecation/Sunset-заголовки. То есть вместо самодельных фильтров теперь есть один официальный механизм.

В контроллерах появляется новый атрибут version:

@GetMapping(path = "/account/{id}", version = "1.1")
public Account get() { ... }

Хочешь гибкости — прописываешь "1.1+", и метод будет жить до тех пор, пока ты явно не создашь новую версию. Функциональные эндпоинты тоже подтянулись — у них теперь есть предикат version("1.2").

На клиентской стороне — ApiVersionInserter, который один раз настраиваешь:

RestClient client = RestClient.builder()
    .baseUrl("http://localhost:8080")
    .apiVersionInserter(ApiVersionInserter.useHeader("API-Version"))
    .build();

// И дальше только версия
client.get().uri("/account/1")
    .apiVersion(1.1)
    .retrieve()
    .body(Account.class);

Тестовые клиенты работают по той же логике.

Статья на Хабр "Нативный API Versioning в Spring 7: долгожданная официальная поддержка"
Демо-проект с тестами и примерами
Документация

😭 Технический долг — это больно. А архитектурный?

В новой статье очень чётко объясняется, почему основная проблема не в «грязном коде», а в том, что фатальные перекосы рождаются на уровнях, куда разработчики обычно даже не смотрят.

На уровне приложений всё вроде просто: слишком много сервисов, половина — SaaS, данные лежат где попало. Это тот случай, когда «немного архитектурного долга» превращается в рост расходов и бесконечные сроки поставки.

А вот бизнес-слой — штука коварнее. Когда процессы не документированы, «владельцы» непонятны, а «фантомные» схемы живут в Confluence с 2017 года, компания начинает строить планы на неверных предпосылках. Тут уже не про код — тут про то, что неправильная схема процессов может парализовать пол-организации быстрее, чем любой упавший микросервис.

И наконец — стратегический уровень. Это та точка, где неверно определённые бизнес-возможности превращают многолетнюю стратегию в упражнение «стрельнули мимо, но уверенно». Стратегический долг редко заметен сразу, но именно он блокирует трансформации и закрепляет ошибочные решения на годы вперёд.

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

Статья на Хабр "Почему архитектурный долг опаснее технического?"

🍃 DockerHub ломает пайплайны, Spring AI идёт в наступление, а собесы становятся жёстче | Spring АйО Подкаст №42

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

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

🚀 Spring Framework 7.0 — новая эпоха Spring официально началась

Spring команда выкатили GA релиз Spring Framework 7.0 — это старт нового поколения фреймворка с фокусом на Java 25 и фундамент для Spring Boot 4.0, который на момент выпуска поста пока не вышел в GA.

Что нового:
🛑Поддержка Java 25 (LTS) при сохранении baseline на Java 17
🛑Переезд на Jakarta EE 11: Servlet 6.1, JPA 3.2, Bean Validation 3.1
🛑Широкая адоптация JSpecify в рамках всей экосистемы Spring
🛑Поддержка Jackson 3.0 (2.x пока можно, но уже deprecated)
🛑Kotlin 2.2 и JUnit 6.0

Из новых фич, которые стоит посмотреть:
🛑Программная регистрация бинов (более гибкий подход, чем XML/аннотации)
🛑Core resilience features — встроенная устойчивость к сбоям
🛑Новый JmsClient
🛑API versioning на уровне фреймворка
🛑Расширенная конфигурация HTTP Interface Client
🛑RestTestClient для более удобного тестирования HTTP

Обратите внимание, что для Spring Framework 6 и 7 одинаковая baseline версия Java - 17. Если вы уже используете Java 17, то для перехода на Spring Framework 7 вам не потребуется повторно обновлять версию JDK.

Тем не менее, Java 25 постепенно станет дефолтом для enterprise-приложений на Spring

🎲 Сравнение собеседований в 8 крупных технологических компаниях

В новом переводе от команды Spring АйО Пунит Патвари недавно принял предложение о работе в Atlassian на должность ведущего инженера-программиста (Principal Software Engineer). За три месяца он прошёл более 60 собеседований в 11 компаниях, как он мне рассказал, и отказался ещё от трёх процессов после того, как согласился на предложение от Atlassian — включая собеседование в Meta.

* Meta признана экстремистcкой организацией в России

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

😎 Работа с объектами в HTTP-запросах

Работать с объектами намного удобнее и безопаснее, чем со строками: IDE подсказывает поля, типы проверяются на этапе компиляции – меньше шансов ошибиться.

Connekt, построенный на Kotlin DSL, позволяет использовать все эти преимущества при работе с HTTP-запросами — результат можно сразу сохранять в объект, а затем передавать его дальше по сценарию, например, в следующий шаг авторизации или повторно использовать данные без лишнего парсинга.

😏 Больше фич для работы с HTTP

🎉 Встречаем Spring AI Agents и Spring AI Bench

Java-разработчикам теперь доступен мощный инструментарий для работы с агентными ИИ-системами: Spring AI представила проекты Agents и Bench.

В новом переводе от команды Spring АйО рассмотрим, как первый обеспечивает удобную абстракцию для работы с CLI ИИ-агентами, а второй — предлагает реалистичные бенчмарки для оценки их эффективности в задачах enterprise-разработки.

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

🎯 Ну всё! Теперь точно Final

Относительно недавно вышел JDK 25, про который мы активно писали. Через полгода будет релиз JDK 26 который, помимо прочего, таргетирует JEP 500, который стремится сделать final поля на самом деле final.

В данной статье на Хабр, эксперт сообщества, Михаил Поливаха, поведает про краткую историю вопроса с final, что с final в Java не так, и как Java платформа докатилась до жизни такой.

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

🍃 Spring АйО на Java Rock Star Meetup

Недавно прошла офлайн-дискуссия с нашим участием, на которой удалось поднять вечные вопросы: "Стоит ли платить за коммерческую поддержку?", "Зачем нужна LTS-версия?".

Поговорили про релизы Java и Spring, про отношения вендоров и заказчиков и про то, почему стабильность — понятие растяжимое.

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

🐳 DockerHub удаляет старые JDK теги — ваши пайплайны могут быть под угрозой

Если вы используете openjdk:<tag> образы в CI/CD и пулите их с Docker Hub, Вам следует оперативно перепроверить свои пайплайны: мейнтейнеры DockerHub удалили ряд устаревших тегов без громких анонсов. Некоторые сборки уже не работают — пострадали сотни пользователей.

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

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