Spring и Hibernate: как очищать тестовые данные без @DataJpaTest

Hibernate ORM 6.2 добавил SchemaManager: его метод truncateMappedObjects() очищает все таблицы, связанные с JPA-сущностями. В интеграционных тестах Spring очистку можно запускать в @BeforeEach, а затем заново добавлять исходные записи через TransactionTemplate.

Так тесты не приходится оборачивать в транзакцию @DataJpaTest. Иначе тестовый EntityManager остаётся доступен после вызова сервисного метода и может инициализировать ленивые прокси, хотя в рабочей среде они уже вызвали бы LazyInitializationException. Часть SQL-операторов также может не выполниться, а целостность базы останется непроверенной.

Очистка в начале теста надёжнее @AfterEach: при сбое или остановке в отладчике завершающий метод может не выполниться. В разборе Vlad Mihalcea есть полный пример с последовательными и параллельными переводами между счетами.

В Quarkus 3.37.0 появился новый вход к реляционным данным

Экспериментальное расширение Quarkus Data Hibernate объединяет работу с реляционными базами в одной зависимости. Оно поддерживает расширенные сущности, репозитории с аннотацией @Repository, блокирующий и неблокирующий режимы, а также запросы на чистом SQL. Реализации репозиториев генерируются при компиляции с проверкой запросов и параметров по модели сущностей.

Для новых приложений команда предлагает начинать с Quarkus Data Hibernate. Реактивная работа требует отдельной зависимости quarkus-hibernate-reactive, поэтому состав приложения остаётся управляемым.

Panache 1 продолжит работать, планов удалять его нет. Инструменты миграции ещё разрабатываются, так что существующие кодовые базы можно переводить без спешки. Расширение войдёт и в Quarkus 4.0; архитектура и ограничения описаны в блоге Quarkus.

Quarkus 3.31.2: как измерить покрытие runtime-модулей расширений

До версии 3.31.2 расширение quarkus-jacoco учитывало код из @QuarkusTest, но не покрытие runtime-модулей в QuarkusUnitTest. Именно такие тесты обычно составляют большинство в расширениях. Причина в сборке: Quarkus применяет офлайн-инструментирование JaCoCo к архивам приложения, а runtime-модуль расширения обычно к ним не относится.

Теперь артефакты для инструментирования можно явно указать через свойства group-id и artifact-id. Для одного расширения конфигурация добавляется в deployment-модуль, после чего отчёт создаётся автоматически.

Для многомодульного проекта статья показывает, как собирать данные всех тестов в общий файл и строить единый отчёт по зависимым расширениям. Это помогает находить непроверенные участки и регрессии до релиза. Готовые конфигурации Maven приведены в руководстве Quarkus.

Как профилировать Java-приложения с JDK Flight Recorder

JDK Flight Recorder (JFR) встроен в OpenJDK и записывает события JVM с небольшими накладными расходами. Его можно использовать для постоянного наблюдения за приложением, а собранную телеметрию разбирать при снижении производительности или сбоях в продакшене.

Материал показывает, как начать работу с JFR, записать данные и перейти к их анализу. Отдельные сценарии посвящены поиску узких мест, утечек памяти и проблем с потоками. Для долгоживущих Java-сервисов это способ исследовать поведение JVM на данных с работающего приложения.

Практические сценарии и демонстрации собраны в материале Inside.java.

Как Spring AI 2.0 исправляет структурированный вывод по JSON Schema

Обычный entity(TalkSubmission.class) строит схему из Java-типа и преобразует ответ модели в объект. Если небольшая локальная модель пропустит поле или вернёт недопустимый null, запрос завершится ошибкой 500.

Новый validateSchema(...) сверяет JSON со схемой. При ошибке Spring AI передаёт модели причину и повторяет вызов, по умолчанию до трёх раз. Режим выключен по умолчанию, поэтому существующие вызовы entity после обновления не меняют поведение.

В статье Dan Vega показан пример на Spring Boot с Anthropic и Ollama, а также настройка журнала повторных попыток. Для миграции проверку можно включать точечно там, где нестабильный JSON уже приводит к ошибкам.

Quarkus 3.29: что изменилось в тестах CDI-компонентов

QuarkusComponentTest запускает не всё приложение, а только CDI-контейнер и сервис конфигурации. Тестируемый бин остаётся реальным, а отсутствующие зависимости автоматически заменяются моками Mockito. Их можно внедрить через @InjectMock и настроить в тестовом методе.

В Quarkus 3.29 переработали загрузку классов. Расширение теперь поддерживает преобразование байткода, упрощённую инъекцию через конструктор, final-классы и методы. Новый SPI позволяет подключать логику до сборки и после запуска контейнера. Интеграция с quarkus-panache-mock добавила компонентные тесты для Panache-сущностей.

В обзоре Quarkus также разобраны жизненный цикл контейнера, автоматический выбор тестируемых компонентов и изменения версий 3.13 и 3.21.

Как показать вызовы инструментов в интерфейсе на Spring AI 2.0

Spring AI 2.0 вынес цикл вызова инструментов из реализаций отдельных моделей в цепочку советников ChatClient. Теперь его можно обернуть собственным советником, увидеть промежуточные события и показать пользователю, какой метод выполняется до появления ответа модели.

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

В разборе есть рабочий проект на Spring Boot 4.1: инструменты с @Tool, потоковый контроллер и советник для отслеживания вызовов. Подход пригодится, если интерфейсу корпоративного ИИ-сервиса нужна наблюдаемость без изменений внутри модели.

Value-классы в JDK 28: где JVM убирает аллокации, а где возвращает их

JEP 401 вошёл в JDK 28 как предварительная возможность. Отказ от идентичности позволяет JVM хранить поля без ссылок и раскладывать компоненты по регистрам или стеку, но ускорение не гарантировано.

Неизменяемые поля JVM может хранить плоско, а для изменяемых выбирает ссылку, чтобы потоки не увидели значение из частей разных записей. JIT-компилятор C2 способен убрать создание value record в цикле, но стирание типов и виртуальный вызов могут вернуть объект и аллокацию.

Перед миграцией проверьте горячие участки и переходы между представлениями: три таких случая разобраны в статье Value Classes Still Need Compiler Sympathy.

Почему ref = null обычно не помогает сборщику мусора JVM

Локальная ссылка в стеке потока остаётся корнем GC, пока её фрейм активен. После выхода из метода сборщик её не обходит, поэтому ref = null перед возвратом обычно ничего не меняет.

Сборщик копирует достижимые объекты в другой пул, а прежний затем использует заново. Он сохраняет всё, до чего может добраться от корней, а не удаляет мусор по одному объекту.

Редкое исключение возникает, когда узлы LinkedList лежат в разных поколениях памяти: разрыв связи с обработанной частью иногда сокращает удержание. Но рост памяти требует искать ошибку жизненного цикла: растущую статическую коллекцию, кеш без вытеснения или слушатель без отписки. Разбор стека и достижимости помогает отличить утечку от лишнего присваивания.

Как перенести Spring Boot 3.5 на 4.1 и не пропустить тихие поломки

Поддержка Spring Boot 3.5 закончилась 30 июня 2026 года на версии 3.5.16. При этом проект может собраться и запуститься с устаревшими стартерами: зелёной сборки для миграции недостаточно.

До перехода включите предупреждения об устаревших API и прогоните тесты. Затем проверьте зависимости: spring-boot-starter-web стал spring-boot-starter-webmvc, а Flyway получил отдельный стартер.

Пошаговая миграция проекта разбирает Jackson 3, переход от MultiValueMap к HttpHeaders и тесты: @MockBean заменён на @MockitoBean, а @SpringBootTest больше не настраивает MockMvc, WebClient и TestRestTemplate. Это чек-лист мест, которые надо проверить после компиляции.

Как перевести сборку Gradle на Isolated Projects

Isolated Projects параллельно конфигурирует проекты, ускоряя локальные сборки и синхронизацию IntelliJ IDEA. Функция экспериментальная и требует совместимости с Configuration Cache.

Команда Gradle начала с help, собрала нарушения в диагностическом отчёте и затем проверила IDE и CI. Плагины соглашений изолировали логику проектов, а обмен артефактами шёл через зависимости.

Опыт внедрения команды Gradle показывает порядок миграции: сначала локальные сборки, затем CI. Продакшен-артефакты пока собирают без этой функции, пока не подтверждена корректность результатов.

Как ускорить агрегацию в Spring Batch с помощью DuckDB

В Spring Batch агрегацию миллионов строк можно вынести из Java-цикла с HashMap в SQL-запрос DuckDB внутри Tasklet.

В тесте на Java 21 и DuckDB 1.5.5: 10 млн строк обработались за 0,17 секунды вместо 1, 50 млн — за 0,61 вместо 4,83. На свежем запуске JVM влияет прогрев JIT, поэтому результаты лучше перепроверить на своих данных.

Схема интеграции и исходный код пригодятся для агрегаций и соединений. Классическую обработку оставьте для внешних вызовов и обогащения каждой строки.

HotSpot: как задачи JIT задерживают выгрузку ClassLoader

JIT создаёт для горячего метода задачу CompileTask: она держит ссылку на метод, класс и его загрузчик. Пока поток C1 или C2 не завершит компиляцию, GC не выгрузит загрузчик.

Поэтому тест после System.gc() может срабатывать нестабильно. Повторный полный GC иногда мешает компиляторам закончить работу.

Для диагностики дайте JIT время либо отключите фоновую компиляцию флагом -XX:-BackgroundCompilation. Это делает удаление задач предсказуемее, но добавляет скачки задержки. Тест с URLClassLoader и PhantomReference показывает этот сценарий.

Vaadin и Spring: как собрать интерактивный Java-интерфейс

Во второй части проекта NeuroWatch интерфейс на Vaadin дополняют диалогами, формой с валидацией и обновлением данных в реальном времени. Приложение использует Spring Security, Kafka и MongoDB.

Выбор строки в таблице открывает карточку: метаданные размещены в FormLayout, связанные записи — во вложенном Grid. Вкладки позволяют добавить форму редактирования, а Binder связывает её поля с Java-объектом и проверками.

Редактирование показывают только пользователям с ролью ADMIN. При этом проверка роли в интерфейсе не защищает данные сама по себе: ограничения нужно повторить на уровне сервисов и репозиториев.

Схема диалогов, форм и обновлений пригодится для Spring-приложений, где серверный Java-код управляет состоянием интерфейса.

Gradle 9.5.1 в одноразовом CI: сокращаем запуск сборки

В свежем CI-контейнере нет состояния предыдущего запуска, поэтому Gradle снова получает дистрибутив и готовит служебные файлы. Для Java-проекта это лишнее время до выполнения задач сборки.

В разборе запуска Gradle проверяют три приёма: использовать дистрибутив -bin вместо -all, восстанавливать каталоги Wrapper и заранее готовить generated-gradle-jars вместе с jars-9. Версии образа и Wrapper нужно согласовать, а после обновления Gradle пересобрать подготовленный образ и проверить пути кэша.

Результаты служат ориентиром: небольшой Spring Boot-проект собирали в чистом Docker-окружении по пять раз, базовый прогон занял 31,7 секунды. Повторите замеры на своей кодовой базе: в крупной сборке больше времени могут отнимать зависимости, конфигурация или выполнение задач.

Как проверить отправку Kafka-сообщения в Spring Boot без Docker

В интеграционном тесте с Embedded Kafka настоящий брокер запускается внутри тестового процесса. Аннотация @EmbeddedKafka создаёт топик greetings, поэтому внешняя Kafka и Docker не нужны.

KafkaTemplate публикует сообщение, а отдельный KafkaConsumer получает запись через KafkaTestUtils.getSingleRecord. Перед отправкой тест считывает сообщения, созданные ApplicationRunner при запуске, чтобы проверка не забрала старую запись.

Тест подтверждает доставку от продюсера до брокера и обратно к потребителю, но не результат работы метода с @KafkaListener. Эффект обработчика стоит проверять отдельно: так транспортная интеграция и бизнес-логика не маскируют ошибки друг друга.