Версию зависимости агент называет по памяти, но klibs.io отдаёт её из живого индекса через MCP
Просите ассистента добавить библиотеку, а он вписывает в pom.xml версию, которой в Maven Central нет или которая отстала на год. Сборка падает, либо вы тянете артефакт с уже закрытой уязвимостью: версия взята из обучающих данных, а не из репозитория.
JetBrains показала обходной путь: у каталога klibs.io (4200+ проектов, данные из GitHub и Maven Central) появился MCP-сервер. Агент ходит в него запросом по платформе и цели, среди которых есть JVM, и получает последнюю опубликованную версию пакета из индекса.
Каталог собран вокруг Kotlin Multiplatform, так что enterprise-стек закрывает частично. Интереснее приём: справочник по зависимостям как инструмент рядом с агентом. Если ваши ассистенты уже правят pom.xml, проверьте, откуда они берут версии, и до тех пор держите ревью зависимостей ручным.
1 ноября записи в DynamoDB начнут падать там, где сегодня проходят, но это проверяется заранее
Вызов, попавший в троттлинг, SDK сейчас молча повторяет до девяти раз, и запись доходит. С 1 ноября 2026 AWS меняет дефолты ретраев: у DynamoDB останется четыре попытки вместо девяти, у прочих сервисов три вместо четырёх, пауза при троттлинге вырастет с 500 мс до 1000 мс.
По логам не понять, кого это заденет: наружу выходит успех или финальная ошибка, а попытки между ними SDK не показывает. В AWS SDK for Java 2.44+ новые значения включает переменная AWS_NEW_RETRIES_2026=true, но это рубильник: цена выясняется в бою.
Ответ даёт библиотека retrylens: ExecutionInterceptor пишет каждую попытку в кольцевой буфер, а симулятор считает по этим записям, чем бы тот же трафик кончился на новых дефолтах. Запросы он не переотправляет и ключи доступа не просит, так что снять картину можно на проде.
Устаревшие API можно удалять без лотереи в большой Java-кодбазе
Метод годами помечен @Deprecated, но удаление может сломать неизвестного потребителя. ArchUnit рассчитан на JUnit-проверку одного репозитория, чего мало для общих библиотек.
Nebula ArchRules поставляет правила вместе с библиотекой отдельным JAR. Gradle-плагин запускает их там, где библиотека подключена как зависимость. Анализ байткода делает одно правило общим для Java, Kotlin и Scala.
В CI-сборке авторы видят проекты, которые используют устаревшие, экспериментальные или непубличные API. Netflix TechBlog разбирает решение: 358 правил уже работают более чем в 5000 репозиториев и находят почти миллион нарушений. Так потребителей можно найти до изменения общего API.
Solon Cloud позволяет менять сервисную инфраструктуру без переписывания бизнес-кода
Планируете менять реестр сервисов, центр конфигурации или шину событий без каскада правок в бизнес-логике? Solon Cloud ставит между кодом и инфраструктурой общий слой: приложение вызывает CloudConfigService, CloudDiscoveryService или CloudEventService, а запрос выполняет выбранный плагин.
Всего набор определяет 13 сервисных интерфейсов. Для перехода с локальной реализации на Nacos или Consul меняются зависимость и YAML-конфигурация, а бизнес-код остаётся прежним.
В разборе Solon Cloud на DEV Community есть схема слоя и полный перечень интерфейсов, включая хранение файлов, задания, распределённые блокировки и генерацию идентификаторов. Для крупной кодовой базы это способ заранее оставить путь к смене инфраструктуры.
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.