Java *

Каждый процесс в вашей компании — наследие прошлого. Жёстко? Возможно. Но логика верна. Каждый бизнес-процесс, который ваша организация выполняет сегодня, был спроектирован для мира без ИИ. Всё — от цепочек согласований до последовательностей передачи задач и обработки исключений — было построено на человеческом суждении. И всё это было выстроено вокруг предположения, что программное обеспечение может автоматизировать задачи, но координировать работу будут люди. Это предположение больше не работает.

После выхода Claude Opus 4.7 стало очевидно, что агент технически быстрее меня. А 28 мая Anthropic выпустила Opus 4.8 с теми же ценами, заметно лучшим coding/agentic-скором и новой возможностью держать в голове миграции на сотни тысяч строк

Знает он, кажется, всё. Все фреймворки, все паттерны, всю историю последних пятнадцати лет на StackOverflow и GitHub. По объёму знаний это легко сеньор, местами принципал

Но при всём этом ему не хватает трёх вещей

В новом переводе от команды Spring АйО рассмотрим ленивую инициализацию в Java , которая почти всегда значит: поле сначала null, потом double-checked locking, volatile, синхронизация. Ошибиться легко, а final не поставить. Итог - код хрупче и JVM хуже делает constant folding.

В JDK 26 (preview, JEP 526) добавили LazyConstant<T>: final поле, рецепт вычисления через Supplier, значение доступно черезget(). Supplier выполнится при первом get и только один раз успешно, даже при гонке потоков. Кроме этого значение помечается как @Stable - JVM может считать его константой и агрессивнее оптимизировать.

Граничные случаи: null нельзя; не сериализуется; исключение из Supplier пробросится и следующая попытка снова пересчитает; equals у LazyConstant - только identity.

Для 1:n есть List.ofLazy и Map.ofLazy: элементы/значения считаются по индексу/ключу по требованию и кэшируются.

В проде connection pool редко падает громко — чаще он тихо превращает сервис в очередь ожидания: запросы висят, база задыхается, Kubernetes начинает перезапускать поды, а в логах всплывает знакомое Connection is not available.

В этой статье разбираем пять настроек HikariCP, которые чаще всего крутят «на глаз»: размер пула, minimumIdle, maxLifetime, keepaliveTime и connectionTimeout. Покажем, почему «поставить побольше» почти всегда плохая идея, как таймауты инфраструктуры ломают соединения и какие метрики стоит вывести в Grafana, чтобы увидеть проблему до инцидента.

Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными разработчиками !

Java Telegram API обманывает разработчиков дубликатами запросов при отключении интернета?

Мы команда разработки телеграмм ботов, которая смогла придумать решение для работы с дубликатами в Statefull командах Telegram API используя REST. Прошли путь от наивного решения до работающего продукта.

Статья о том как Я начал разработку собственной Idea и чуть не бросил 2 раза эту затею. Как я выбрал неподходящий готовый пакет редактора кода, и начал разработку своего снова.

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

Меня зовут Михаил Поливаха. Я думаю, что в Хабе Spring АйО меня уже относительно знают. В рамках Spring АйО мы довольно часто занимаемся подбором технического материала и его ревью. Сам же я довольно регулярно выступаю на конференциях, контрибьючу в Open Source и т.д.

Также, часто наши материалы крутятся вокруг Java разработки и конечно же Spring-а. И данной пост, хоть и будет с одной стороны сильно связан с Java и Spring Framework, но, тем не менее, не похож на остальные.

На днях произошло довольно знаковое событие. Мы с небольшой командой примерно год писали инструмент, который призван существенно упростить весь процесс отладки, тестирования и мониторинга Spring Boot приложений в production. И вот этот проект наконец-то получил первый Milestone Релиз.

Проект называется Axelix.

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится?

В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking.

Откуда берётся «среднее приложение с GitHub»? Если попросить агента создать JPA‑сущность или настроить Spring Security, то он выдаст вполне рабочий код. Вопрос только в одном: для какого проекта?

Модели натренированы на миллионах репозиториев: студенческие работы, всех задолбавшая Petclinic, туториалы с YouTube, у меня кстати, есть куча своих:D.

Но без чёткого контекста агент выдаёт типичное «среднее приложение с GitHub»: всё синтаксически верно, но далеко не всегда вписывается в существующий РЕАЛЬНЫЙ проект. С Lombok или без него? Используя @IdClass или @EmbeddedId? Предпочитаешь Record'ы или классические классы? Как у тебя маппятся DTO? Агент этого не знает и чаще всего либо пытается угадать, либо начинает грепать всё что можно и нельзя.

Prompt engineering помогает, но ненадолго. Прикреплять каждый раз примеры сущностей и архитектурные правила — прошлый век. Интеграция в IDE с @ и выбором файлов уже лучше, но всё равно надо постоянно об этом помнить и как РОБОТ писать ему одно и тоже.

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM?

В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

Микросервисы обещают масштабирование и независимость команд, но чаще ломают систему медленнее монолита. Почему?

В статье разбираем семь архитектурных ошибок, которые можно встретить в реальных системах: выбор по моде, shared database, игнорирование network latency, операционная сложность на потом, слишком мелкая декомпозиция, отсутствие стратегии consistency, недооценка сроков миграции.

Оказывается, документация Claude Code рассказывает не всё. Стоило только лишь заглянуть в исходники. И вот что можно настроить, но чего нет в доке:

— hooks, которые переписывают команды на лету;
— автоодобрение safe-команд без лишних подтверждений;
— постоянная память агентов между сессиями;
— auto-mode, который понимает описание окружения на обычном английском;
— самообучающиеся циклы памяти и «снов»;
— скрытые поля skills, agents и permissions, которых нет в документации.

И все это работает уже сейчас, а исходники Claude Code лежат у вас в node_modules. Мы собрали все в статью. Там больше конкретики, JSON-конфигов, shell-хуков и примеров, которые можно утащить себе почти без правок.

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Как-то раз на одном из программистских форумов я наткнулся на интересную задачку. Интересна она была тем, что требовалось рекурсивное решение на Java. Мне захотелось разобраться…

Cursor, Copilot и другие AI‑инструменты обещают быстро закрыть рутину с unit‑тестами: сгенерировать кейсы, расставить моки, добавить ассерты и поднять покрытие. Но зелёные тесты ещё не означают, что код защищён от регрессий.

В статье разбираем пять типичных паттернов, из‑за которых AI‑сгенерированные тесты выглядят убедительно, но пропускают реальные баги.

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

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

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

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

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?

Привет, Хабр! Меня зовут Александр, я Java-разработчик в GlowByte. Работаю в практике управления рисками и комплаенс (Risk & Compliance). Хочу поделиться своим опытом и в целом рассказать о том, чем мы здесь занимаемся. А занимаемся мы автоматизацией систем управления рисками – от AML (противодействие легализации доходов) и операционных рисков до коллекшна (взыскание просроченной задолженности) и систем принятия решений.

Моё направление – как раз последнее: системы принятия решений (СПР). Если коротко, мы автоматизируем стратегии, где нужно в реальном времени перерабатывать кучу входных параметров, учитывать множество факторов и выдавать сложные, комплексные решения. Типичные примеры: оценка риска, предстраховые проверки, системы мониторинга, расчет резервов, расчет комиссионных вознаграждений страховым агентам и многое другое.

Чем это интересно? На выходе – не просто «да/нет», а полноценное управляемое бизнес-правило, которое можно быстро менять без переписывания кода.

В этой статье хочу поделиться опытом разработки backend API на Spring Boot-проекте, где нам пришлось много работать с OpenAPI-спецификацией, динамическими запросами и тестированием бизнес-логики.

У нейросетей есть ограничение на количество символов в чате или на число запросов. И бывает так, что лимит уже закончился, а разработка проекта — нет.

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

Отдельная проблема — DeepSeek не всегда понимает ссылки на репозиторий и не смотрит код по ним так, как хотелось бы. Зато если дать ему сам контекст кода текстом, он включает его в анализ.

Системный аналитик пишет User Story, рисует BPMN, описывает API — а через месяц архитектор перекраивает всё, потому что «это не ложится на DDD». Знакомо?

В этой статье я показываю пошаговый маршрут, как аналитику самому спроектировать доменную модель и перенести её в Java‑код. Разбираю на реальном кейсе: Event Storming, выделение ограниченных контекстов, построение агрегатов с инвариантами и асинхронное взаимодействие через интеграционные события.