Телеграм канал «Чашечка 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 секунды. Повторите замеры на своей кодовой базе: в крупной сборке больше времени могут отнимать зависимости, конфигурация или выполнение задач.

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

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

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

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

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

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

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

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

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

Как ускорить агрегацию в 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, поэтому результаты лучше перепроверить на своих данных.

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

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

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

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

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

Как перенести 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. Это чек-лист мест, которые надо проверить после компиляции.

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

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

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

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