🌱 Некоторые детали реализации 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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