Java *

Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.

Я уже выпускал статью по мотивам вопросов в рамках Spring Айо Академии. Так вот, когда мы разгребали отзывы с первого потока, мы также получили вопрос (это не прямая цитата, я лишь передаю посыл в том виде, как я его понял):

А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?

И я за время дизайна enterprise систем, и за время дизайна Axelix пришёл к выводу: Просто не используйте натуральные ключи вообще никогда. Когда у вас появляется такое желание - выйдите на свежий воздух, пройдитесь, прогуляйтесь, и вас отпустит.

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

Подготовка спецификации, написание тестов до кода и отдельное ревью требуют времени разработчиков. Возникают два вопроса: сколько контроля нужно конкретной задаче и когда затраты на него окупаются?

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

Выпущен Jmix 3.0, и это самый значительный шаг, который фреймворк сделал за последние годы. Этот релиз перестраивает основу на современном технологическом стеке, оставаясь полностью совместимым с предыдущими версиями, что делает миграцию гладкой и простой. Наряду с обновлением платформы, 3.0 представляет набор функций, которые активно используют ИИ и предоставляют гибкость в рантайм.

Ниже приведён краткий обзор основных новых возможностей. Полный список изменений, включая все критические изменения, доступен в разделе Что нового документации.

Всех приветствую!

Данная статья будет посвящена довольно важным вещам, таким как: refresh token, метод-уровневой безопасности и примеру реализации правила "свой/чужой профиль"

После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений

Я всё чаще вижу один и тот же сценарий. Агент получает задачу, за несколько минут собирает патч, запускает тесты и сообщает об успехе. Первый просмотр выглядит обнадёживающе. Потом начинается ревью.

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

В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.

Как часто, работая с агентом над новой фичей, вы остаётесь недовольны результатом? То что-то не работает, то качество кода неприемлемо. Вы просите агента ещё раз и ещё раз, пытаетесь подобрать «идеальный» промпт — и всё равно не выходит. Уверен: чем дольше вы работаете с агентом, тем чаще разочаровываетесь. И это неудивительно: агент пишет код очень быстро — и именно поэтому ОЧЕНЬ просто получить ОЧЕНЬ много кода, который вам не нужен. Но код — это как раз простая часть. Настоящая задача инженера — строить системы: надёжные, быстрые и поддерживаемые. Именно за это нам и платят — и вот этого агент пока за нас не делает.

Origami Framework — фреймворк для автоматизации тестирования на Java, созданный с целью упрощения построения тестовой архитектуры и ускорения процессов приёмочного и регрессионного тестирования

Несмотря на то, что IntelliJ IDEA уже несколько лет официально недоступна в России, она по-прежнему остаётся одной из самых популярных IDE среди разработчиков. На днях вышла свежая версия 2026.2.

В релиз вошли новые инструменты для работы с ИИ-агентами, изменения в отладчике и автоматизация ряда повседневных операций. Также появилась поддержка Java 27, Kotlin 2.4, TypeScript 7, будущего Gradle 10 и обновления для Spring, Terraform и Docker Compose.

В статье пройдемся по основным изменениям.

Если вы Java-разработчик, которому в личных целях нужно поднять TLS 1.3 на ГОСТ, создать ГОСТ-сертификаты, подписать документ CAdES, создать свой тестовый УЦ, сделать шифрование и подпись на своем Android — эта статья для вас. Все примеры в этой статье одинаково работают что на JVM 21, что на Android 12+.

crypto-gost —   криптографическая библиотека алгоритмов ГОСТ на Java 21+ и Android 12+, а также сопутствующая обвязка вокруг них, позволяющая использовать в личных целях алгоритмы и стандарты ГОСТ в инфраструктуре Java. Статья написана в академических целях.

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

Strict‑режим включён, схема валидна, ответ успешно парсится — а в проде всё равно всплывают None, пропавшие ограничения и аргументы инструментов не тех типов.

В статье разберём пять ситуаций, где Structured Outputs создают ложное ощущение надёжности, и посмотрим, какие проверки действительно стоит добавить в LLM‑пайплайн.

Локально Testcontainers запускается за секунды, тесты стабильно зелёные, а в CI тот же набор начинает падать в трёх запусках из ста и каждый раз по новой причине.

В статье разберём пять типовых источников такого поведения — от плавающих версий образов и неправильного ожидания готовности до конфликтов портов и нехватки памяти — и покажем, как сделать интеграционные тесты воспроизводимыми на пайплайне.

Привет, друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

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

Я обещался на все эти вопросы ответить в рамках статьи. На самом деле, одной статьи у меня не вышло, скорее всего, будет серия статей. Надеюсь, будет интересно :)

Привет, Хабр! Меня зовут Александр Бардаш, и я CTO интеграционной платформы MWS Octapi. В одной из предыдущих статей я рассказывал, как мы выбирали движок для low-code и почему остановились на Temporal, отказавшись от Apache Camel. С тех пор регулярно получаю один и тот же вопрос — от продактов, аналитиков, а иногда и от коллег-архитекторов: «Подождите, ну сейчас же есть Karavan, Kaoto, нормальные визуальные редакторы. Аналитик там накидает кубики, настроит логику, разве это не cделает Camel доступнее?» Короткий ответ — нет, не cделает. А вот почему, предлагаю разобрать в материале.

Дисклеймер: это мой личный опыт и опыт команды. Тема спорная, у вас может быть своя картина.

Меня заинтересовал новый плагин DB Client, который идёт в составе OpenIDE. Давайте посмотрим, может ли он уже на текущий момент стать достойной альтернативой платному DataGrip? Я не предъявляю каких-то узкоспециальных требований к таким инструментам. В основном требуется писать и оптимизировать sql-запросы, просматривать структуру таблиц и диаграмму связей между ними, просматривать актуальный DDL, выполнять мелкие правки данных “на лету”, а также делать импорт и экспорт данных в различных форматах. Давайте по этим пунктам и пройдёмся.

Открой свой Spring-проект, которому больше двух лет. Найди пакет common, core или framework — а он там есть, я почти уверен. Загляни внутрь.

Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.

Поздравляю: ты написал фреймворк. Свой, внутренний, недокументированный (себя-то не обманывай), поддерживаемый одним человеком (который уже собеседуется в другую компанию). И построил ты его ровно для того, чтобы не брать «тяжёлый и навязчивый» opinionated-фреймворк — ты сделал это «ради контроля».

Давай честно поговорим про этот контроль.

Наконец-то неплохо продвинувшись в написании своего мультиплатформенного приложения Modern Money мне понадобилась аутентификация для Kotlin Multiplatform.

Хотелось иметь один API для PIN-кода и биометрии, а под капотом использовать Android Biometric Prompt, Windows Hello, Touch ID.

Так появился Koncierge — набор KMP-модулей biometric, auth и auth-compose

Казалось бы, задача довольно стандартная: объявить expect-класс и написать несколько actual-реализаций. На Android это примерно так и получилось. А вот Windows Hello, JVM-модуль и публикация всех артефактов заставили немного разобраться в том,

В многомодульных Gradle-проектах рано или поздно появляются вспомогательные классы для тестов: фабрики тестовых данных, билдеры, хелперы. Такие классы не относятся ни к продакшн-коду, ни к обычным тестам. Логично было бы переиспользовать их сразу в нескольких модулях, но классическая модель Gradle этого не позволяет: тестовые артефакты одного проекта нельзя просто так подключить как зависимость в другом. 

На самом деле Gradle умеет решать эту задачу из коробки без вспомогательных проектов и хитрых конфигураций. Начиная с версии 5.6, тестовые фикстуры стали в Gradle полноценной сущностью первого класса, и весь этот пласт боли можно убрать буквально несколькими строчками в build.gradle.

Плагин java-test-fixtures заводит в модуле отдельный SourceSet, а другие модули подключают эти классы через лаконичный DSL. При публикации Gradle даже собирает отдельный *-test-fixtures.jar для независимых проектов. В статье на примерах показано, как расшарить тестовые хелперы между модулями, избавиться от дублирования и при этом сохранить чистые архитектурные границы. Если вы устали таскать тестовый код из модуля в модуль, то Вам точно пригодится.

Привет, Хабр! В этой статье я расскажу об эволюции подсистемы сериализации one-nio — фреймворка для создания высоконагруженных сервисов, работающего в Одноклассниках с 2012 года. Прошлой осенью я работал над обновлением подсистемы и добавил в нее новый режим работы, совместимый с актуальными версиями JDK.

Ситуация, с которой мы столкнулись, довольно прозаична. Библиотеке больше десяти лет, и экстремально быстрая сериализация (превращение объекта в последовательность байтов и обратно) с самого начала строилась в ней на внутренних лазейках JVM, к которым обычный прикладной код доступа не имеет. Когда one-nio только писали, это был стандартный паттерн для высоконагруженных фреймворков.

Сейчас же платформа методично «закручивает гайки»: старые бэкдоры помечаются как устаревшие, а затем безжалостно удаляются. И перед нами встал серьезный вызов: как перевести библиотеку на легальные API вплоть до JDK 25, сохранив производительность и не сломав то, что годами крутится в проде?

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

Всем привет! Данная статья посвящена регистрации и аутентификации с помощью JWT что помогает нам избавиться от тяжёлых сессий и куки и быть более крутыми и современными разработчиками