Java *

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

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

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

Это конспект вебинара. Спикер — Даниил Степанов, разработчик-исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

Если коротко: проблема чаще всего не в том, что "модель тупая". Проблема в том, что вокруг агента нет инженерного контура: спецификации, ограничений, независимых тестов, security-checks, ревью-пайплайна и артефактов, которым можно верить.

Миграции базы данных вроде бы есть, Liquibase подключен, changelog лежит в репозитории, CI зелёный, релизы проходят регулярно. Значит, процесс под контролем?

Не всегда…

Почему добавление второго consumer«а в очередь может привести к двойным списаниям? Разбираем на реальном кейсе: как один Topic стоил компании 312 дублей за час. »

Сравниваем поведение JMS, Kafka и RabbitMQ, показываем, почему ни одна очередь не даёт exactly‑once из коробки, и как идемпотентность, Dead Letter Queue и правильный выбор канала (команды vs события) делают интеграции надёжными.“

Готовые схемы, продакшен‑код на Java и чек‑лист, который стоит применить прямо сейчас!

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

В последней части про модели конкурентности JVM языков мы сравним разные подходы друг с другом. И ответим на вопрос “А зачем теперь тред пулы, если есть столько модных концепций: корутины, файберы, виртуальные потоки ?”

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin эксперементально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Разбираемся полностью в новом переводе от команды Spring АйО.

Что будем делать или что может быть интересного в статье:

- Пайплайн из двух независимых LLM агентов

- Запуск и анализ ошибки UI автотеста (Root Cause Analysis)

- Фикс автотеста в цикле с его запуском.

- Кастомизация MCP инструментов чтобы оптимизировать контекстное окно.

- Система приоритетов в работе LLM агентов.

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

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Coroutine, Fiber, Virtual thread - это всё одно и то же?

Или нет ?

Или нет.

А если под капотом всё равно JVM, почему нельзя просто везде включить virtual threads и успокоиться? Разберемся!

Я сравнил Codex 5.3, Claude Opus 4.6 и GPT-5.5 на реальном многомодульном Java-монолите: скопировал проект в отдельные ветки, дал агентам похожие задачи и прогнал их через цикл правок, ревью и e2e-тестов.

Результат: чем дешевле - тем лучше результат.

В статье рассмотрим ряд техник GenAI, реализованных в модуле Spring AI, и ответим на вопрос: является ли ChatClient лишь тонкой оберткой над API провайдеров LLM или предоставляет функциональные возможности, которые имеет смысл применять в реальных проектах. В качестве примера будем итеративно разрабатывать приложение, интегрированное с Anthropic, и разбирать возникающие по ходу проблемы.

Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять.

В какой-то момент я поймал себя на мысли:

А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой?

Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов?

Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV.

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

Давайте попробуем еще раз, в прошлый раз как-то не задалось, но много воды утекло с тех пор. Проект начался как простой способ "заглянуть в БД сервера" собственно таким он и остается до сих пор. Но по мере развития ИИ в нем появились новые фишки.

Как гласит слоган на главной странице: Panopticum — место, откуда видно всё. Собственно я старался сделать его именно таким, чтобы можно было посмотреть и проверить как можно больше из одного места, желательно с одинаковым интерфейсом.

Сначала я просто начал наращивать количество коннекторов. И если сначала это было четыре вида БД, потом шесть, то теперь это 26 разных БД, логи из Kuberneties и просмотр S3 бакетов.

Долго думал, в каком формате это написать, в итоге решил по-простому - рассказать, что есть, и кому это может пригодиться.

Мы с коллегой делали выпускной проект для курсов CloudJava и CloudJava K8S. Это техзадание на бэкенд распределенной системы - четыре микросервиса, Gateway, обвязка. Изначально оно было доступно только участникам курсов, теперь решили открыть бесплатно, без регистрации или “оставьте email”. Просто страница с текстом и тремя OpenAPI-спеками.

Ссылки сразу, чтобы не листать:

Описание проекта: https://javaops.ru/view/cloudjava3

Само ТЗ: https://javaops.ru/view/cloudjava3/rescue-service.html

Вы пробовали что-нибудь кроме new Thread() ?

Конечно пробовали: Future !

И всё ?!

Разберемся с разными моделями конкурентности в Java, Kotlin, Scala/ZIO и Clojure: у всех JVM под капотом, но подходы разные. Начнём с разбора тредов, пулов, virtual threads из Project Loom и Structured Concurrency. Дальше: корутины, fibers, ZIO runtime и Clojure.

В новом переводе от команды Spring АйО рассмотрим выход Spring Boot 4 и Spring Framework 7. InfoQ взяли интервью у core команды Spring с целью узнать, куда движется самая популярная в Java экосистема.

Spring Boot 4 модуляризировал автоконфигурацию. Теперь при запуске проверяется меньше классов в classpath, а uber-jar будет более компактным: будут подключаться только нужные модули. Параллельно Spring Boot 4 переходит на Jackson 3, но добавлен модуль совместимости с Jackson 2, потому что экосистема ещё догоняет.

Spring Framework 7 тащит core resilience в ядро: RetryTemplate, @Retryable и @ConcurrencyLimit доступны без отдельной зависимости. @Retryable работает и с реактивными типами (через Retry из Project Reactor); для обычных вызовов используется RetryTemplate с политикой retry/backoff. @ConcurrencyLimit помогает ограничивать доступ к ресурсу, что особенно полезно с Virtual Threads.

Хабр, привет!

В последнее время обсуждать миграцию с продуктов SAP – это база. Однако для многих компаний эти системы пока остаются ключевыми.

Типичная защита периметра: «свои» внутри, «чужие» снаружи. Но бывает инверсия. Заказчик открывает SAP NetWeaver AS Java в большой мир. SAML в этой системе активируется быстрее, чем вы моргнете — буквально в два клика. Но если на том конце провода не дремлет злоумышленник, а у вас нет 2FA… считайте, что ключи от дома вы спрятали под ковриком.

Мы столкнулись с этой болью на проекте у одного из заказчиков. Нужно было настроить двухфакторную аутентификацию. И вот тут начались нюансы.

В этом материале мы опишем настройку интеграции портала SAP NetWeaver AS Java с внешним Identity Provider (IdP) — Keycloak — с реализацией двухфакторной аутентификации (2FA). До нашего вмешательства аутентификация происходила напрямую в SAP-системе.

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

Далее кратко рассмотрим процесс настройки и разберем возникшие проблемы.

Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.

Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.