Телеграм канал «Чашечка Java»

Spring разводит настройку бина по этапам жизненного цикла контейнера

У PostConstruct, InitializingBean и процессоров разные места в цикле. Поэтому точку расширения стоит выбирать после того, как определён обрабатываемый объект.

До создания экземпляров BeanFactoryPostProcessor работает с определениями бинов. BeanPostProcessor обрабатывает созданный экземпляр до и после инициализации. Для инициализации есть @PostConstruct и InitializingBean, для очистки: @PreDestroy и DisposableBean. SmartLifecycle координирует запуск и остановку компонентов с активным состоянием.

В материале на DEV Community эти точки собраны в примерах с тестами и документацией. При ревью сначала определите этап контейнера, затем выбирайте точку расширения.

Пакетные задачи Spring AI с DeepSeek выгоднее запускать по расписанию

Пакетная генерация через DeepSeek V4 теперь зависит от времени запуска. С 16 августа часы пик идут с 01:00 до 04:00 и с 06:00 до 10:00 UTC. В остальные 17 часов тариф вдвое ниже пикового.

Эта скидка действует только относительно нового пика. Для V4 Pro вне пика миллион входных токенов подорожал с $0,435 до $0,66, выходных: с $0,87 до $1,98. Попадание в кеш стало дороже в шесть раз даже по внепиковому тарифу.

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

«Невозможная» порча базы может прятаться ниже вашего приложения

Если резервная копия не проходит проверку целостности, а логи приложения не показывают причину, привычный путь диагностики обрывается. Именно так Tailscale полгода искала источник порчи SQLite-баз в своём контуре управления: 19 случаев без закономерности и возможности повторить сбой по запросу.

Условия выглядели безопасно: к базе каждого шарда обращался один Go-процесс, полные снимки каждые несколько минут уходили в S3. Причина всё же оказалась в SQLite: ошибка жила там не менее 16 лет.

Для Java-команд этот кейс полезен как методика расследования сбоев, которые документация считает невозможными. В разборе на DEV Community остались ход поиска и чек-лист для Spring Boot с Postgres, MySQL или SQLite.

На JVM серверный HTML до сих пор собирают шаблонами, хотя соседние экосистемы давно перешли на компоненты

Вёрстка живёт в шаблонах Thymeleaf или FreeMarker: опечатка в имени поля всплывает в рантайме, а рефакторинг в IDE до неё не дотягивается.

JetBrains разбирает в блоге Kotlin, как закрыть этот пробел. Библиотека Compose HTML уже собирает веб-интерфейс на Kotlin поверх Compose-рантайма и компилирует его в JS. Если добавить JVM-таргет, те же компоненты отрендерятся в HTML на сервере: автодополнение, рефакторинг и проверки компилятора вместо строковых шаблонов.

В посте: почему нынешняя отрисовка Compose для веба в canvas ломает SEO, скорость загрузки и доступность.

Это исследование, а не анонс релиза: обязательств JetBrains не берёт. В план миграции не ставить, а вот в список на перепроверку положить стоит.

Совет не оптимизировать руками и довериться JIT держался на цене специалиста, а она рухнула

В любом Spring Boot сервисе есть эндпоинты, которые тормозят годами: снять профиль, найти горячий метод, проверить гипотезу, откатить. Несколько дней инженера ради неочевидного выигрыша.

Дэн Лу в эссе «There's no reason for software to be slow anymore» пишет, что человеко-время на такую итерацию упало в тысячи раз: запуск агента на его собственном сценарии с ripgrep занял около двух минут. Джейми Брэндон отдал агенту недоделанное тестовое Anthropic по производительности и получил результат лучше своего.

Java стоит на обратном: пиши предсказуемый код, JIT разберётся. Это верно, пока проверка гипотезы дороже выигрыша. Теперь она стоит минуты, зато поддерживать неочевидные правки в горячем пути всё равно людям. Рабочий процесс для Spring Boot. Пустили бы агента в горячий путь своего сервиса?

Общий обработчик исключений убирает try/catch из контроллеров, но свалка переезжает в него самого

В контроллере на каждый эндпоинт по два catch: свой UserAlreadyExistsException в 409, остальное в 500 со строкой «Internal server error». В соседнем контроллере то же самое, но статус и текст уже другие. Всё это уносится в @RestControllerAdvice, и метод снова возвращает только успешный ответ.

Спор начинается дальше. В статье на dev.to автор разводит бизнес-ошибки и системные. Вторые обычно закрывают одним обработчиком на Exception.class, и он же превращает в аккуратный 500 то, что должно было упасть громко и попасть в алерты.

А со Spring Boot 3 в фреймворке уже есть ProblemDetail: стандартное тело ошибки по RFC. Свой ErrorResponse при этом всё равно пишут почти все.

Как разложены исключения у вас?

Промпт прошёл все офлайн-проверки и всё равно уронил P95 на 38%, но канареечный выкат ловит это за минуты

Правку промпта не отсекает ни один привычный гейт: компилятор её не видит, юнит-тесты зелёные, офлайн-набор из 40 кейсов тоже. А на живом трафике переформулированное описание инструмента научило агента вызывать его дважды за ход: вызовов на диалог стало 5,4 вместо 3,1, P95 вырос на 38%. Тестовые транскрипты короткие по замыслу, реальные диалоги длинные, и каждый лишний вызов удваивает ожидание.

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

Если промпты у вас едут в прод вместе с кодом, начинать стоит с процента трафика, который возвращается в ноль одной настройкой, и графика вызовов инструментов на диалог.