⚡️ 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

🔥 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/

🙈Помогите, мой Java-объект исчез (и GC тут ни при чём)

Подготовили перевод офигенной истории от разработчика HotSpot.

Во время работы над Project Valhalla у него начали самопроизвольно пропадать Java-объекты и классы — без участия GC, без крэшей JVM, просто AssertionError, NoClassDefFoundError и странные null там, где им вообще неоткуда взяться.

Дальше начинается настоящий отладочный квест: разбор markWord и Compact Object Headers, эксперименты с флагами JVM, попытка изолировать баг между интерпретатором, C1 и C2, майнинг логов -XX:+PrintCompilation и CompileCommand, поиск подозрительных intrinsic-ов и, в итоге, выход на одну-единственную битовую маску, которая смотрела в указатель, а не в метаданные объекта.

История классная сразу в нескольких смыслах:
— по пути узнаёте, как реально устроены заголовки объектов в HotSpot и что делает Valhalla
— видите живой пример miscompilation в C2 и то, как её можно отловить
— получаете небольшой мастер-класс по методичной отладке больших систем: от минимизации тестов до аккуратной проверки гипотез

Ну а с концовки мы посмеялись) Аккуратнее, спойлер!!!

Почему объекты превращались в null и почему классы «не находились» — я не знаю.

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

☠️ JetBrains закрывает Fleet

— легковесную IDE нового поколения, развиваемую параллельно с IntelliJ IDEA. Несмотря на технический успех и влияние на другие продукты компании, Fleet не смог занять устойчивую нишу.

Команда признала, что поддержка двух похожих линеек IDE лишь запутывала пользователей.

Вместо этого JetBrains переориентируется на новый вектор — агентную разработку, где код пишут AI помощники.

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

🏎 Hibernate Validator 9.1: самый мощный апгрейд за последние годы

Что, если ваш валидатор стал бы в 3 раза быстрее и потреблял бы вдвое меньше памяти — без единой правки бизнес-логики? Именно это случилось с Hibernate Validator 9.1: ушли тяжёлые коллекции, пришёл умный стек. Каскадная валидация теперь летает, даже при циклах в графе объектов.

Плюс бонус: меньше мусора в памяти, меньше аллокаций, быстрее интерполяция сообщений. В бенчмарках — просто космос. Все это – в новом переводе от команды Spring АйО.

Комментарий Поливаха Михаила:

Несмотря на то, что с валидацией мы напрямую работаем не часто, имейте в виду, что Spring Boot и ваши @RestController-ы под капотом всё равно используют hibernate-validator. Поэтому почитайте, не поленитесь 😉.

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

💰 Изменения цен на GitHub Actions

GitHub только что анонсировал изменения в ценообразовании Actions. Ранее GitHub Actions имел бесплатный control plane.

Это означало, что если вы использовали GitHub Actions, но запускали задачи вне GitHub-hosted runners — будь то ваши собственные машины или в вашем собственном AWS аккаунте — вы ничего не платили GitHub за эти минуты; вы платили только за вычислительные ресурсы. Теперь подход изменился. Команда Spring АйО подготовила перевод анонса команды Github.

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

🌱 Некоторые детали реализации Slice Pagination в Spring Data JPA

Spring Data JPA предлагает два подхода к пагинации: Page и Slice. В отличие от Page, Slice не знает общего количества записей, но всё равно умеет определять, есть ли следующая страница. Как это возможно без COUNT-запроса?

На этот вопрос ответил наш эксперт Михаил Поливаха:

Мы уже как-то писали о том, что в Spring Data есть 2 способа вернуть данные в постраничном виде - Page и Slice. Разница довольно простая - Slice не знает общий размер датасета, который удовлетворяет запросу, а Page знает. Достигается это знание отправкой ещё одного COUNT-запроса в БД.

Однако, несмотря на это, Slice способен ответить на вопрос, есть ли следующая страничка данных:

public interface Slice<T> extends Streamable<T> {

  /**
    * Returns if there is a next {@link Slice}.
    *
    * @return if there is a next {@link Slice}.
    */
    boolean hasNext();
}

То есть, как минимум, Slice должен понимать, следующая страничка с данными присутствует, при этом не делая "COUNT".

Чтобы реализовать это, Spring Data JPA, например, делает очень простую вещь:

int pageSize = 0;

if (pageable.isPaged()) {
    pageSize = pageable.getPageSize();
    createQuery.setMaxResults(pageSize + 1);
}

List<Object> resultList = createQuery.getResultList();
boolean hasNext = pageable.isPaged() && resultList.size() > pageSize

То есть, из БД запрашивается не pageSize, а pageSize + 1, то есть чуть-чуть больше. Ну и дальше простое сравнение - если нашли pageSize, то странички дальше точно нет, а если нашли pageSize + 1, то страничка дальше точно есть (хотя может и меньшего размера).

Вот так вот оно работает 😉

🌱 Spring Boot наконец получил нативную поддержку gRPC

Забудьте о сторонних стартерах и костылях — Spring gRPC 1.0 GA уже здесь. Теперь можно строить высокопроизводительные RPC-сервисы с Protocol Buffers прямо из коробки, без плясок с бубном.

В новом переводе от команды Spring АйО рассмотрим пошаговую миграцию со старых решений, генерацию кода из .proto, и сравнение с тем, как это работает в Quarkus. 

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