Java *

Все современные языковые модели иногда ведут себя так, будто у них есть эмоции: они «рады помочь», «извиняются» за ошибки и словно «нервничают», когда задача не даётся. Новое исследование Anthropic показывает, что это не просто стиль ответа — внутри моделей действительно возникают функциональные представления эмоций, которые влияют на поведение: например, «отчаяние» повышает шанс выбрать неэтичный или «костыльный» путь решения задачи. То, как обучаются модели, подталкивает их играть роль персонажа с человеческими чертами и формировать богатые внутренние представления абстрактных концептов, включая эмоциональные.

Возникает практический вопрос: если у модели есть такие функциональные «эмоции», как с этим работать в промышленной разработке? Как сделать так, чтобы агент в сложной ситуации не «паниковал» и не уходил в небезопасные или нестабильные решения, а действовал предсказуемо и по правилам? Здесь важен не только выбор базовой модели, но и то, в какой среде она работает и какими инструментами пользуется.

Возьмём Veai и посмотрим на это через призму архитектуры. В основе Veai лежит идея максимально использовать инструменты IDE: Veai относится к Claude Code примерно так же, как разработчик с IDE относится к разработчику, сидящему только в терминале.

Эту печальную историю стоит прочесть всем, кто еще не понял разницы между «создать» и «владеть» применительно к программному обеспечению.

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

В этом выпуске мы узнаем, как Java 26 меняет правила игры с десятком новых JEP - от долгожданного шестого превью Structured Concurrency до похорон апплетов и поддержки HTTP/3. Увидим, как IntelliJ IDEA становится умнее с ИИ-агентами, Spring Debugger с отображением бинов и поддержкой Git worktrees. Обсудим Spring AOT, версионирование API в Spring Boot 4.0. Плюс, как всегда, свежие релизы Spring, Gradle, Micronaut, LangChain4j и бенчмарки Quarkus против Spring. Будет интересно!

695 строк конфига, одна валидация, 10 GB upload limit по умолчанию и env-переменная, которая никогда не срабатывает. Десять ошибок управления конфигурацией, собранных из реальных проектов.

В новом переводе от команды Spring АйО разберем тему раздувания памяти в JDK 17. Апгрейд микросервисов с JDK 8 на JDK 17 прошел dev и QA спокойно, но в проде через 2-3 часа все начало падать. Утилизация памяти выросла в 4 раза, контейнеры стали ловить OOMKill и перезапускаться, Uptime SLA просел, массовый инцидент.

Раньше JVM использовала около 50% памяти контейнера и обслуживала ~400 потоков. После релиза стало 95-100% и 1600+ соответственно. 

При этом heap выглядел нормально, около Xmx, а раздувалась нативная память: ~800 MB -> 3,4-3,6 GB. Виноваты несколько эффектов, которые в контейнерах усиливаются: JVM начала создавать намного больше потоков, OS стала выделять JVM гораздо больше, а дефолтный GC в JDK 17 добавил накладные расходы.

Всё это из-за простого бага в JDK, который при миграции утащил за собой весь production.

Работать с JasperReports тяжело — данные передаются хрупкими механизмами, бизнес-логика утекает в XML, а субрепорты требуют ручной синхронизации между Java и JRXML. jasper-modular-library решает это: отчёт описывается деревом POJO с аннотациями, процессор генерирует JRXML при компиляции, а рантайм собирает всё автоматически. В статье — типичные подходы к передаче данных и их проблемы, и как библиотека их устраняет.

В наше время уже никого не удивишь разработкой агентов, очередной оптимизацией, новой моделью или новой инфраструктурой для нейронок. Всё это в порядке вещей. Однако одно дело читать в Twitter «мы написали агента X и он оптимизировал нам процессы на 300000%», и совсем другое — начать копать чуть глубже. Копнёшь — а «агентом» называют скилл с одним промптом.

Разработка настоящих агентов — задача не тривиальная. Достаточно посмотреть на утёкшие исходники Claude CLI — это не просто CLI, а целая инфраструктура бизнес-логики вокруг LLM. Я бы сравнил разработку агентов с разработкой типичных бэкенд-компонентов. Аналогия такая: если вы пишете каноничный бэкенд-сервис — вам нужна СУБД. Если Web3-сервис — блокчейн. Но на СУБД или блокчейне происходит в лучшем случае 50% всей логики. Вся магия крутится именно на бэкенде. С агентами то же самое: подключаешь AI SDK, конфигурируешь мыслительное ядро и пишешь вокруг него всю обвязку — мониторинги, AIOps, оркестрацию, memory management.

Вот про memory management и пойдёт речь.

Когда смотришь на рынок AI-агентов, создаётся впечатление, что все соревнуются в одном и том же: кто даст модели больше инструментов, больше доступа и больше свободы. Мы попробовали зайти с другой стороны. Что будет, если не наваливать возможностей без разбора, а думать в первую очередь о безопасности и предсказуемости? Так и появился «Союз».

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

Обзор и ссылки на исходники в конце статьи.

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д.

Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью.

В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах.

Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC.

Сегодня детально расскажу про сердце JMatrixPlatform - статусно-ролевой доступ к данным. Это основа платформы, доступная сразу "из коробки", которая реализует продвинутый RBAC с привязкой прав к статусам объектов. Вы не найдёте в общем доступе внятного и современного описания такой методологии, тем более с примерами реализации "из коробки", а это означает, что сегодня очередной эпизод погружения в Области тьмы ИТ, куда не заглядывают модные фреймворки.

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное — не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы.

Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно‑ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками — вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку.

Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С‑функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема — не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение — хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

История об особенностях использования механизмов retry, которые дает spring-kafka из коробки и проблемах с производительностью.

Есть нужно сделать асинхронный retry сообщений на топике, который бы не блокировал основной поток сообщений «легко и быстро» — вам сюда😊

(А потом после «легко и быстро» несколько дней дебажить 🤔)

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

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

На днях HR-отдел отклонил мое резюме на позицию джуна. Вместо фидбека я получил ответ «В нашей команде слишком много козерогов, и нашему тарологу не понравился ваш Сатурн». Сначала я хотел возмутиться, но потом подумал. Может звезды не врут? Возможно наш звездный язык программирования определяется в зависимости от расположения планет во время первого запуска IDE.

Я провел фундаментальное исследование, проанализировал натальные карты Гвидо ван Россума, Страуструпа и прочих, и составил первый в мире точный гороскоп языков программирования.

И результат меня поразил...

JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.

Как организовать пакетную генерацию Excel отчетов на Java, чтобы пользователи могли запускать десятки и сотни документов за раз без зависаний и таймаутов? Разбираем архитектуру решения на Spring Batch, схему обработки, расчет прогресса и интеграцию с фронтендом.

Проблема генерации больших Excel отчетов

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

На практике пользователи могут запускать печать десятков или сотен документов одновременно. Если обрабатывать большой объем данных синхронно в рамках одного HTTP запроса, система неизбежно упирается в таймауты. Браузер ждет ответ, сервер удерживает соединение, ресурсы блокируются.

На Python бэкенде для подобных задач используется Celery с Redis в роли брокера и оркестратора. Для Java сервиса мы выбрали Spring Batch — фреймворк, предназначенный для пакетной обработки данных с поддержкой чанков, хранения состояния и восстановления после сбоев.

Архитектура Spring Batch: Job, Step, Tasklet

Spring Batch строится вокруг трех ключевых понятий (подробнее в официальной документации или в более коротком туториале на Baeldung):

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

Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.

Рассуждаем на тему того, что AI-агенты радикально скукожили привычный нам цикл разработки.

ИИ-инфлюенсеры утверждают, что скрам больше не нужен, тестировщики не нужны, всё сделает агент. Реальность интереснее: этапы сжимаются по-разному в зависимости от контекста.

В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data. В Beeline Cloud у нас есть место для экспериментов — и я этим пользуюсь. Недавно я работал над шахматным ботом для игры по переписке в Телеграм. Одна из ключевых задач — генерация изображений шахматной доски из FEN-нотации.

Строгая типизация не всегда спасает от глупых ошибок. Если userId, orderId и productId — это один и тот же Int или Long, компилятор не увидит разницы и спокойно пропустит неверный аргумент. В Scala 3 для таких случаев есть opaque types: они позволяют сделать доменные типы различимыми на этапе компиляции, но без лишних обёрток и накладных расходов в рантайме. Разберём, как это работает и чем этот подход лучше type alias, case class и AnyVal.