Java *

Когда смотришь на рынок 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.

В новом переводе от команды Spring АйО смотрим, как подружить современный Spring Boot и OpenTelemetry так, чтобы данные уходили по OTLP в любой совместимый бэкенд. 

В экосистеме Spring большая часть телеметрии была завязана на Micrometer Project (Был ещё spring-cloud-sleuth если кто помнит). Но полноценного all-in-one решения для того, чтобы Spring Boot приложение просто начало экспортировать телеметрию по OTLP не было. До Spring Boot 4.

На данный момент для интеграции OTel в Spring Boot приложения есть 3 пути: Java Agent (минимум кода, но чувствителен к версиям и может конфликтовать с другими агентами), сторонний OTel starter (стартер от самих OpenTelemetry, но тянет alpha-зависимости) и новый spring-boot-starter-opentelemetry, доступный в Spring Boot 4.0. Про него и будет речь.

Представим, перед командой разработки встает задача. Необходимо реализовать конвейер ипотечных заявок.

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

Было решено реализовать конкретный процесс с помощью low-code платформы Nuxeo, чтобы понять, где она действительно упрощает жизнь, а где добавляет новые ограничения.

Когда команда пишет API, но документация живёт своей жизнью, а интеграторы часами гадают, что значит ошибка 500, — проект неизбежно тонет в хаосе. В этой описан подход, который является лучшим решением: Design‑First на основе OpenAPI.

Мы пройдём полный цикл: от проектирования спецификации до работающего Spring‑приложения с автоматической генерацией кода и централизованной обработкой ошибок.

Вы узнаете, как одна команда ./gradlew clean build может создать модели и интерфейсы, избавив вас от рутины.

При сборке Java приложения в нативный образ требуются настройки для работы рефлексии, прокси и других динамических механизмов Java. Зачем, если JVM справлялась с этим сама? Разбираем отличия между миром статической компиляции и динамической Java.

Доброго дня

В 2011 году у нас была идея сделать на web онлайн mind-web доску и недавно идея воплотилась в реальность.

Название приложения — «Наброски», или WebSketch, ссылка.

Релиз Veai 5.7 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) собрал в себе много исправлений неочевидного UX, с которым вы сталкивались ежедневного. Меньше ручных переключений, меньше ожидания между шагами, меньше повторов при сбоях.

Долгое время я пытался научиться слепому десятипальцевому методу печати, но всегда это заканчивалось поражением. Учился на Keybr — на нём освоил английский. Частотный метод, когда ты печатаешь настоящие слова из самых частых букв, мне подошёл. Но столкнулся с тем, что заглавные буквы, пунктуация и цифры спрятаны за кучей настроек. Подумал — зачем это прятать, если можно сделать структурированные этапы и дать чёткий путь прохождения? Так я начал разработку TypeStep — тренажёра слепой печати с частотным методом и этапами прохождения. А теперь — про то, на чём это всё построено и с чем пришлось столкнуться.