Java *

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

Первое, что приходит в голову, это VisualVM или JDK Mission Control. Однако во время разработки приложения удобнее не переключаться между инструментами, а открыть состояние процесса прямо в IDE.

Для этого мы в OpenIDE выпустили Profiling Tools — плагин для мониторинга и исследования Java-приложений. Его разработкой занималась команда Axiom JDK.

В этой статье разберём, что из себя представляет Profiling Tools и как с его помощью можно быстро и удобно разобраться что не так с приложением.

В прошлой статье про PostgreSQL я разбирал три инцидента на стороне базы — блокировки, bloat и ночные пересчёты. В комментариях несколько человек написали примерно одно и то же: «база базой, а покажи, что творилось на стороне приложения — пул-то небось тоже горел».

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

Авторизация в Spring обычно живёт в аннотациях и SpEL — и ломается на иерархии ресурсов и фильтрации списков. Как вынести правила доступа в OPA, не потеряв ни фильтрацию в SQL, ни fail-closed. Первая статья серии про open-source Spring Boot starter для ABAC на Open Policy Agent.

📅 Когда: 18 сентября, сбор в 18.00, начало в 19:00.
📍 Где: Москва, м. Бауманская, Лофт Casa Picassa, Бауманская ул., 11, стр. 8. Зал Кандинский.
🎟 Формат участия: офлайн.

Участие бесплатное, но обязательно предварительно зарегистрируйтесь.

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

Есть такая традиция — «велосипеды изобретать». Очень часто при интеграциях с другими информационными системами обращаю внимание на то, какие подходы там используются в части управления процессами согласования или другими действиями над рассматриваемым объектом: где‑то делают только уведомления («вам пришёл документ на согласование»), где‑то для каждого документа отдельный уникальный тип задач, где‑то подключают BPMN, а где‑то не делают вообще ничего.

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

Каждый Java разработчик в том или ином виде сталкивается с проблемой выбора инструментария для работы с БД. Если говорить про ORM-ы, то выбор у нас невелик: Spring Data JDBC или Hibernate. И тут часто возникает набор вопросов:

- Когда выбирать Hibernate, а когда Spring Data JDBC?

- Как дизайнить Aggregate-ы в Spring Data JDBC?

- Что из DDD просто теория, а что реально важно на практике? и т.д.

Мы оттекстовали доклад Михаила Поливаха с прошедшего Spring I/O Barcelona. В докладе обсуждаются все эти и многие другие вопросы, с которыми часто сталкиваются люди при проектировании доменной модели в целом.

Будет полезно, если присматриваетесь к Spring Data JDBC или уже используете его и накопили вопросы.

⚠️ А если хочется глубже погрузиться в разработку реальных приложений, у нас в Академии скоро стартует новый поток «Java в продакшене». 

В прошлой статье я рассказывал, как мы перевозили терабайт банковской базы с Oracle на PostgreSQL без даунтайма. Там был раздел про производительность, и в комментариях несколько человек спросили примерно одно и то же: «а что конкретно вы дебажили и как?».

Это продолжение. Три инцидента из двух разных проектов — банковской системы после миграции и enterprise-платформы на Java/Spring, где PostgreSQL жил под Hibernate. Разные домены, разные команды, но сюжет один: запрос, который вчера работал, сегодня не работает, а EXPLAIN показывает, что всё хорошо.

Если вы пришли в PostgreSQL из Oracle или из мира, где база — это «то, куда ORM пишет», три четверти статьи будут про вещи, о существовании которых вы не подозревали. Я тоже не подозревал.

Дисклеймер: проекты под NDA, названия, объёмы и часть деталей изменены. Порядок величин и сами инциденты — настоящие.

У Spring за один день вышел 91 CVE — больше, чем за весь прошлый год, — и нашел их в основном AI-сканер. Oracle впервые за двадцать лет выпустила патч безопасности вне квартального цикла. А еще уже совсем скоро (15 сентября) выходит JDK 27. Обо всем этом и не только рассказываем в свежем выпуске 🙂

Как я собрал бесплатный сервис метаданных книг на Java и Spring Boot — с EAV/Pivot-схемой БД вместо ALTER TABLE на каждое новое поле, агрегацией нескольких открытых источников. Плюс обновлённый плагин для Obsidian.

В статье представлена переработанная текстовая версия доклада, прочитанного на JPoint 2026 с некоторыми дополнениями.

Речь пойдет об изменениях, которые произошли в сборщике мусора G1 в версиях JDK с 17 по 25, а также дано краткое введение в то, как сборщик мусора устроен.

Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна.

Речь исключительно о технических ошибках при разработке игры на LibGDX, которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL.

Причём в первую очередь я говорю о мобильных играх и WebGL-версиях, которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны.

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

В новом переводе от команды Spring АйО на простом Java-примере показываем:

– как работает мутационное тестирование с Pitest;  
– почему 100% покрытия недостаточно;  
– откуда берутся выжившие мутанты;  
– почему не стоит прогонять MT по всему проекту;  
– и в каких случаях этот подход действительно окупается.

А ещё как поручить настройку и запуск Pitest AI-агенту с помощью готового skill.

Всё, что ниже — из живого пет-проекта: бот начисляет участникам голосовых каналов баллы лояльности (LP), а на эти баллы люди устраивают пари в стиле Twitch Predictions.

Привет, Хабр! Я Артём Борисов, Java-разработчик, в основном занимаюсь развитием микросервисов в команде РСХБ «Свои инвестиции». Представьте ситуацию: вы работаете с инвестиционными сделками, обрабатываете миллионы сделок в день, но все они обрабатываются один раз только ночью. А бизнес требует реального времени. Это была наша рутина, пока мы не внедрили Kafka Streams. В этой статье я расскажу о том, как мы трансформировали систему обработки сделок на фондовом рынке (SOFR) с batch-обработки на полноценную real-time систему, способную обрабатывать миллионы сделок в сутки.

Я довольно активно использую ИИ в разработке примерно с конца 2024 года.

Наверное, многие слышали оценки в духе: «ИИ ускоряет разработчика на 20–30%». Возможно, для каких‑то привычных задач это и неплохая метрика.

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

За один очень плотный рабочий день — примерно 11 часов от идеи до боевого переключения — удалось исследовать закрытый Windows‑компонент, восстановить недокументированный бинарный протокол, разобраться с особенностями криптографии, написать совместимую реализацию на Java, сформировать регрессионный корпус из реального трафика, завернуть всё в контейнер, развернуть в Kubernetes, провести независимое ревью и переключить production.

И вот после такого слова про «+30% производительности» начинают казаться немного смешными.

Честно говоря, это пока самый впечатляющий кейс разработки с AI, который у меня был. Восторг скрывать не буду:)

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

В статье описан пример решения для логирования на базе Spring AOP, с помощью которого можно автоматически логировать входящие HTTP-запросы в контроллерах, отслеживать исходящие запросы через WebClient, гибко управлять видимостью чувствительных данных через аннотации, а также автоматически отключать маскирования в зависимости от уровня логирования.

Конфигурация Spring Boot приложений гораздо более сложная, чем может показаться на первый взгляд.

В новом переводе от команды Spring АйО, мы вместе постараемся внести небольшую ясность в этот процесс.

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Забыли забрать ежедневные гемы или потеряли счёт круткам до гаранта? Рассказываю, как я решил собственную проблему и разработал GachaPoint — бесплатный офлайн‑компаньон для Genshin Impact, Honkai: Star Rail и Zenless Zone Zero без бэкенда и рекламы.

В статье разбираю техническую изнанку проекта для Android (Java / Architecture Components): Зачем использовал «плоскую» таблицу в SQLite (Room) для календаря и как это ускоряет выборки за один запрос, Почему для сетки дней кастомный GridLayout оказался удобнее RecyclerView, Как настроить точные ежедневные напоминания через WorkManager с учётом жестких ограничений Doze Mode в Android 12/13+.

Исходники проекта открыты, буду рад обсудить архитектуру и UI‑решения в комментариях!

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

Так я вернулся в геймдев и начал разрабатывать собственные игровые проекты. Мне был нужен инструмент для 2D‑игры с версиями для Android и браузера, который позволил бы сохранить общий код, не прятал бы происходящее за визуальным редактором и не заставлял бы отказываться от привычной Java‑экосистемы.

В итоге я выбрал libGDX.

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

В этой статье расскажу, что именно мне дал libGDX, какую часть кода действительно удалось сделать общей и где кроссплатформенность закончилась.