Java *

Что делать, если произошла ошибка? Житейская мудрость говорит, что можно попробовать еще раз. 

В контексте разработки ПО существует известный и простой паттерн для повышения отказоустойчивости — retry.

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

Привет! Меня зовут Петр Деменев, я Java-разработчик в MTC Web Services. В материале расскажу о нашем горьком, но успешном опыте внедрения политики ретраев в реальный проект и о неочевидных особенностях, с которыми мы столкнулись. В тексте будет акцент не на строгих теоретических канонах, а на реальной жизни, чтобы приземлиться на уровень практического опыта. И попутно расскажу о некоторых способах ретрая.

Не война двух языков (хоть и бывает), не разные идиомы и взгляды на реализацию делают инструмент “плохим”, а по классике - забивание гвоздей молотком и карго-культ

As we say, two of the most complicated problems in software are naming things and versioning software

Когда-то в кулуарах Devoxx Belgium нечто подобное сказал Томас Вюртингер, лид проекта GraalVM, поясняя детали вот этой нашумевшей статьи. Это не точная цитата, а лишь фраза, призванная обратить внимание на проблему. О ней сегодня мы и поговорим.

Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix.

Довольно давно я хотел написать небольшую статью про версионирование ПО в целом, поскольку, как мне кажется, этой теме незаслуженно достаётся мало внимания. Для многих версионирование заканчивается на SemVer, но тема гораздо, гораздо более обширна, чем может показаться.

Данная статья служит двум целям, быстро освежить знания по ООП и SOLID, а также полезно и весело проектировать роботов с элементами игры средствами языка Java.

* Обложка сгенерирована GigaChat, именно так он видит роботов написанных на языке программирования Java.

В JDK 26 есть JEP 500 — Prepare to Make Final Mean Final. Теперь JVM предупреждает о попытках изменить через deep reflection final-поле объекта, не объявленное как static. В одном из будущих релизов такие операции планируется запрещать, если владелец приложения не разрешил их явно. В статье разберём:

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

Сразу оговорюсь: это не статья про архитектуру, паттерны проектирования, ECS, оптимизацию кода или правильную организацию проекта.

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

Код как хобби за 15 лет в индустрии оставил за собой кладбище пет-проектов. В этот раз Java-оркестратор: git worktree, CLI-сессии, merge request и дашборд для работы. Хроника того, как рос личный инструмент и как на этом кейсе я переосмыслил привычную инженерию.

SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля

Материал носит образовательный характер. Все работы велись легально, в рамках пентеста, с письменного согласия владельца системы и в изолированном контуре. Название клиента и продукта не раскрываем — NDA. Имена классов, пакетов и таблиц в листингах изменены. Применяйте это только на системах, доступ к которым у вас есть. Доступ к чужим системам без разрешения преследуется по закону.

Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.

Разберем, как найти такую в приложении без исходников: декомпиляция JAR → чтение сервлетов → уязвимая строка → подтверждение через pg_sleep. Каждый шаг воспроизводим.

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

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

И это, кстати, не обязательно плохо. Тащить новую фичу в production только потому, что она новая, не самая выдающаяся инженерная стратегия. Более того, многие приложения всё ещё работают на Java 17, а где-то бодро живёт и Java 11.

Но отсюда возникает закономерный вопрос:

Есть ли у новых возможностей Java применение в обычных, реальных приложениях? Не в презентации, не в игрушечном pet project, а в коде, который решает вполне конкретную задачу?

Да, есть.

Что делать, когда процесс разработки с ИИ-агентами уже устоялся, но всё ещё приходиться сидеть рядом с ними и ждать, когда они закончат очередной этап работы, чтобы запустить следующий?

У меня это выглядит так. Появилась идея новой фичи для разработки. Я запускаю /opsx:explore скил OpenSpec и обсуждаю с ИИ как будем делать эту фичу, какие нюансы и детали надо предусмотреть. Когда открытых вопросов не остаётся, перехожу к /opsx:propose, чтобы подготовить спецификации перед разработкой. Потом ревью спек с помощью команды /review-artifacts и правка найденных нестыковок. Дальше запускаю /opsx:apply-sequential для реализации в автономном режиме и чистым контекстом агента для каждой подзадачи. Потом ревью через /audit-implementation и правки после него. Архивирование изменения через /opsx:archive. И наконец-то создание PR, финальное ревью и merge.

И так раз за разом! На простых задачах моё участие сводится к запуску команд и подтверждению предложенных решений. На задачах посложнее отвечаю на вопросы наподобие какую из альтернатив выберем. Хотя этот выбор можно сделать по критериям, зафиксированным в проекте. И это уже начинает утомлять. Пришло время автоматизировать и эту рутину. Так я начал делать свою фабрику, где ИИ-агенты («гномы») трудятся в полностью автономном режиме. А к человеку обращаются только тогда, когда столкнулись с проблемой, которую не могут решить сами.

Java 27 вышла в релиз. В него вошли четыре узконаправленные правки и пять превью/инкубаторов. Разбираем изменения в сборщике мусора, улучшения JFR, постквантовый TLS 1.3 и компактные заголовки объектов, экономящие треть памяти.

🔥 Выходит Java 27!

• Compact Object Headers включаются по умолчанию. Метаданные каждого объекта становятся компактнее, что может уменьшить потребление heap примерно на 20% и снизить нагрузку на GC. Раньше для этого требовался флаг -XX:+UseCompactObjectHeaders.

• G1 становится сборщиком мусора по умолчанию во всех окружениях. Раньше JVM могла выбирать Serial GC на машинах и в контейнерах с небольшим количеством ресурсов. Поэтому после обновления стоит перепроверить память, паузы и CPU именно на маленьких инстансах.

• JFR начинает автоматически скрывать чувствительные данные. Пароли, токены, API-ключи и секреты в аргументах JVM, переменных окружения и системных свойствах больше не должны случайно попадать в запись Flight Recorder.

Уже завтра ожидается выход JDK 27, в которую вошли 9 JEP, связанных с криптографией, диагностическим механизмом JFR, управлением памятью и стандартной библиотекой. В этой статье разберём, что нас ждёт в этом релизе 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, названия, объёмы и часть деталей изменены. Порядок величин и сами инциденты — настоящие.