Java *

Зимой 2024 года мне довелось поучаствовать в разработке проекта на Camunda 8. Сразу оговорюсь: проект в итоге реализовали на другом движке. Тем не менее, команда успела сделать стенд, прогнать тесты и замерить производительность.

В этой статье я расскажу об одном эпизоде, когда мне пришлось исправить библиотеку spring-zeebe из Camunda 8, отвечающую за обвязку Job Worker на Spring.

Одной из моих задач было отладить процесс, используя локальные интеграционные тесты с Docker и библиотекой Testcontainers. Мы создали простой процесс, вызывающий наш Job Worker, подлежавший отладке. Сразу столкнулись с плавающей ошибкой: иногда тест проходил успешно, иногда — нет. Несколько тасков работали корректно, однако первый периодически игнорировался без видимых ошибок. Изначально подозревали проблему в собственном коде, проверяли конфигурацию Job Worker, благодаря чему узнали много нового о Camunda 8.

Может кому пригодится, на просторах интернета не нашел, как запустить модель deepseek в idea, потому сам вместе с deepseek допиливал конфиг и обучал модель работе через инструменты плагина. Ну и попутно решил проблему с зависаниями, плагин очень любил зависнуть, приходилось ide перезапускать.

Сразу оговорюсь, решение не элегантно, я не убирал лишний код, строки и текст, я просто добился рабочего состояния и более ничего не тестировал и не трогал. Годами работы приучен «работает — не трож». Потому решение as is выкладываю. Можете сами эксперименты проводить и допиливать, мне был просто нужен рабочий инструмент, на тюнинг не осталось желания, накрыла лень и я продолжил заниматься изначальным своим проектом =)

В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.

Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс-командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.

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

В этой статье я расскажу, как мы построили локальный RAG-сервис, оформили его как MCP-сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.

Знаю, знаю... Прочитав заголовок, хочется голосом волка из мультфильма «Жил был пёс» сказать — «Шо, опять?». Ведь битва этих подходов давно закончилась и разработчики Spring уже поставили точку.

Но недавняя публикация в одном довольно крупном Telegram‑канале заставила меня вернуться к этому вопросу. В качестве главных аргументов против field injection там приводились лишь сложность изоляции в тестах и неудобство создания экземпляров для unit‑тестов.

И хотя с этими пунктами не поспоришь, у многих разработчиков и не только начинающих, остаются вопросы: каковы реальные последствия для самого объекта? Можно ли считать его полноценным сразу после создания new? И почему все современные рекомендации так настаивают на конструкторах?

Поиск ответов показал мне, что аргумент о тестах лишь верхушка айсберга. В глубине, куда я Вас сегодня приглашаю заглянуть, скрываются куда более фундаментальные вопросы принципов объектно‑ориентированного дизайна, гарантий Java Memory Model и уважения к жизненному циклу объекта.

Бывало ли у вас так что задача на час максимум в результате занимает целый рабочий день или даже больше?

Почему так происходит? Нужно ли тестировать сторонние библиотеки? Есть ли польза от типичных задач для собеседований? Когда "костыль" вполне рабочее решение?

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

Всем привет! 👋👋👋👋👋 Мы Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

Создать Spring-сервис просто: существует масса статей и отличная документация. Однако среди всего этого многообразия материалов зачастую сложно разобраться, какой именно набор технологий лучше выбрать и каким образом эти технологии должным образом интегрировать друг с другом. После перехода на новые версии библиотек многое начинает функционировать иначе, появляются совершенно другие подходы. В данной статье я хочу продемонстрировать один из возможных способов разработки микросервиса в 2026 году, а также рассмотреть несколько инструментов автоматической генерации кода: OpenApiGenerator, JooqCodegen, GigaChat, Liquibase — и объяснить, как они работают вместе в рамках единого проекта.

Точкой отсчета для построения микросервиса сделаем описание REST API. Допустим, в нашем фантастическом мире аналитик заранее подготовил спецификацию API с помощью формата OpenAPI, хотя подобное встречается и в реальной практике.

Когда вы пишете synchronized(obj), под капотом происходит целая цепочка событий, которую можно отследить до Mark Word — восьмибайтового служебного поля в каждом Java-объекте. В современных реализациях JVM (таких как HotSpot, OpenJ9, GraalVM) используется динамическая, адаптивная система, которая выбирает наиболее эффективную стратегию блокировки в зависимости от реального поведения потоков.

Всем привет! Недавно я опубликовал статью, в которой сказал что она будет последней по Easy Maven т.к. все что можно я уже делегировал Maven — импорт проекта, запуск тасков, анализ зависимостей. Но недавнее обилие багов в IDEA 2025.3 связанных как с зависанием так и повышенным потреблением памяти Maven проектами, окунуло меня в баг трекер IDEA, где я нашел много похожих проблем, которые также затрагивают и мавен индексы. Помню как меня самого это раздражало, когда IDEA чуть ли не при каждом открытии, начинает сканировать локальный репозиторий. Про это даже писали в комментариях — где ответ был один — отключить это. Плюс недавно один из постов в тг канале (спасибо за это @javadev), еще больше убедил меня в том, что так дальше жить нельзя и я решил поправить проблему поиска зависимостей так как я ее вижу — не изобретать велосипед, а делегировать поиск туда, где это уже реализовано. Ведь как известно: самый лучший код — тот который ты не написал. Посмотрим что из этого вышло.

Привет, это снова Егор. И да - это снова статья про Фидонет. Так уж сложилось, что именно эта тематика оказался слишком уж популярным на моём Хабре, и неразрывно связана со мной, хотя я всячески пытался "сбежать" от данной тематики.

Однако я решил совместить приятное с полезным - рассказать про недавние мои поправки в NodehistJ, которые значительно ускорит индексацию диффов нодлистов сети Фидонет, а также значительно снизит потребление ОЗУ, за счёт одного из лучших вещей, которая есть в Spring Data JDBC - live streaming данных с СУБД без использования неэффективной пагинации. Данная технология позволяет быстро перебирать нодлисты за считанные минуты, и ускорить индексацию даже на слабых серверах, за счёт прямого перебора данных из СУБД, в live-режиме, без использования неэффективной пагинации, но с использованием самых обычного Java Streams.

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

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

Buckle up, folks!

Мы в OpenIDE хорошо понимаем, что среда разработки — это не просто набор инструментов и функций. Это пространство, в котором разработчик проводит значительную часть своего времени: думает, экспериментирует, ошибается и создаёт новое. Именно поэтому для нас особенно важны открытость, доступность и ощущение живого диалога внутри экосистемы. 

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

И когда до Нового года остаётся совсем немного времени, а сил на сложные технические материалы почти не остаётся, мы решили немного сменить ритм. Вместо глубоких разборов — лёгкое, тёплое и предпраздничное чтение. Так появилась идея серии интервью с участниками нашего комьюнити — людьми, которые создают плагины для OpenIDE.

Hibernate часто работает как надо ровно до того момента, пока не приходит настоящая нагрузка. И тогда выясняется, что безобидные на вид решения отключают batching, ломают пагинацию, умножают число запросов и даже незаметно открывают дополнительные транзакции — ровно там, где вы рассчитывали на один аккуратный запрос в рамках одного unit of work.

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

В своей практике мы можем сталкиваться с хранением и поиском информации задаваемой в интревальном формате. Например: срок действия акций, тарифы на доставку и прочее. В статье мы подружим Spring JPA и Range Types.

С переходом Java на более безопасные и стандартизированные подходы к динамической генерации классов, скрытые (hidden) классы стали ключевым механизмом замены устаревшего Unsafe::defineAnonymousClass. 

Они решают проблемы доступности, управления жизненным циклом и контроля доступа, особенно актуальные для разработчиков фреймворков и языков на JVM. Хотя скрытые классы пока не полностью заменяют функциональность Unsafe, они лежат в основе ряда важных механизмов, такие как, например, реализация лямбд в JDK.

Подробнее - в новом переводе от команды Spring АйО.

2025 год подходит к концу. Minecraft моды, каталонский язык и неочевидные взаимодействия с тернарным оператором — с чем только не успел познакомиться наш анализатор. А значит, самое время вам об этом рассказать — представляем топ-10 ошибок, которые нашёл анализатор PVS-Studio в Open Source проектах за 2025 год.

Когда я работал в одной зарубежной компании, мне поставили задачу мигрировать COBOL‑систему расчета инвойсов с мейнфрейма на Java. Она звучала довольно просто: «Нужно переписать старый COBOL‑код на Java, чтобы система жила дальше».

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

VK Tech открывает исходный код коннектора Tarantool Java EE и переименовывает его в Tarantool Java SDK. Дистрибутив станет доступен в Maven Central, что упростит интеграцию с Java-приложениями в корпоративных средах. 

Меня зовут Артём Дубинин, я старший программист в VK Tech. Я разрабатываю коннекторы к Tarantool, а также участвую в разработке различных продуктов в VK Tech. Однажды я понял, что материала про совместную работу Java и Tarantool очень мало и из-за этого может казаться, что совмещать их сложно. Но на самом деле это не так — и иногда альтернативы Tarantool могут быть даже сложнее во взаимодействии. Поэтому я и решил написать эту статью. 

Цель статьи — показать через код, что Tarantool реально совместить с Java без больших полотен кода, а итеративно с небольшими сниппетами (не считая java импортов и xml 😄). Мы будем использовать такие, чтобы каждый мог попробовать провести у себя на компьютере эти эксперименты и понять, что Tarantool легок в использовании.

Всем привет, меня зовут Анатолий Спитченко, я Android-разработчик в ПСБ. В этой статье расскажу про свои эксперименты с Dagger. Наткнувшись в проекте на огромный модуль Application (11,5 Мб), я стал искать альтернативы обертке Dagger Android. Поэкспериментировал с продвигаемым Google Dagger Hilt, а также с более старым подходом — Dagger Components. Последний, как ни странно, позволяет немного сократить Application и в целом имеет больше плюсов, чем минусов. Подробности под катом.

С появлением виртуальных потоков в Java благодаря Project Loom, параллельное программирование стало проще, а производительность — выше. Однако за этой простотой кроются новые вызовы для инструментов отладки и анализа. Как читать тред-дампы, если их теперь тысячи — или миллионы? Какие средства реально помогают найти взаимные блокировки и аномалии в асинхронном коде? Рассмотрим в новом переводе от команды Spring АйО.