Java *

Переход на новый JDK может изменить поведение сервиса даже без изменений в коде: JVM по-другому выбирает GC, расходует память и обрабатывает старые флаги запуска.

В статье разбираем, что меняет Java 27 внутри рантайма и как проверить готовность сервисов к обновлению.

Всем привет! Это Михаил Поливаха, технический руководитель проекта Axelix (Open Source-продукта, который помогает как дебажить, так и находить распространённые проблемы и неэффективные решения в приложениях Spring Boot).

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

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

Не раз уже поднималась тема про форматтеры для Java, вот всего пару лет назад выкладывали перевод статьи с обзором текущего состояния подобных утилит

Утро четверга. Вы открываете таск-трекер, а там тикет от сканера зависимостей: «jackson-databind, CVE-2026-83557, критично, патчить». Ссылка на GitHub-бюллетень, CVSS, слово «полиморфная десериализация», и через двадцать минут у вас уже согласован hotfix на прод в пятницу в 18:00.

Ресурсы Вселенной ограничены, а постоянно растущее население планеты может привести к голодному вымиранию всего человечества в ближайшем будущем. Чтобы спасти людей от голодного вымирания, киновселенная Marvel придумала оригинальный способ решения проблемы. Создав могущественного титана по имени Танос, взявшего на себя миссию спасителя. Идея Таноса состояла в том, чтобы собрав шесть Камней Бесконечности и объединив их силу в специальной Перчатке, раз и навсегда избавиться от половины населения планеты, просто щелкнув пальцами.

Эта история породила метафорическое значение, а фраза "Щелчок Таноса" стала крылатой и приобрела вполне реальные события. К примеру в бизнесе такое действие иронично называют жесткими антикризисными мерами, когда руководство компании одним махом увольняет большое количество сотрудников, дабы спастись от банкротства.

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

Третья часть серии — практическая. Как подключить библиотеку к Maven-проекту, написать первый модульный отчёт и что после этого происходит с шаблоном при сборке.

Субрепорт — это класс, отчёт — тоже класс, а поля класса и есть содержимое отчёта. Имена параметров шаблона берутся из имён полей, поэтому один и тот же модуль можно поставить в отчёт дважды и получить два независимых субрепорта со своими данными. Аннотационный процессор при компиляции находит существующий JRXML, дописывает в него недостающие параметры, датасеты и банды субрепортов и кладёт результат в target/generated-sources. Шаблон в src он не трогает никогда.

Отдельно — про то, кто владеет шаблоном, когда в один файл пишут и кодогенератор, и человек в Jaspersoft Studio, и где у этой схемы слабое место.

Первая часть — откуда взялся Jasper и почему он так устроен, вторая — один стандарт и три идеи.

Во второй части серии — чего ждёт от инструмента отчётов современный Java-разработчик и на каких идеях я собрал свою надстройку над JasperReports — не переписывая движок и не отказываясь от Jaspersoft Studio.

Один стандарт вместо нескольких способов передать данные: в отчёт едут обычные Java-объекты. Дерево вместо плоской сетки банд: отчёт собирается из модулей, вложенных друг в друга, включая повторяющиеся. Слои: данные добывает Java, вёрстка остаётся в JRXML и в Studio. И объект как единый носитель структуры, данных и имён — вместо одного и того же смысла, продублированного и в XML, и в коде.

Отдельно — ответ на возражение из комментариев к первой статье: зачем вообще выносить выборку данных из шаблона, если Jasper умеет ходить в базу сам.

Первая часть серии — откуда взялся Jasper и почему он так устроен.

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

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

Это не критика. Ядро у Jasper мощное, просто он наследник другой традиции — той, где отчёт является самостоятельным приложением, а не частью вашего.

Один код — и Paper-сервер, и Velocity-прокси: разбираем, как устроены multiloader-плагины для Minecraft и чем они питаются в 2026 году — от архитектуры до сборки.

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

В контексте разработки ПО существует известный и простой паттерн для повышения отказоустойчивости — 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 и компактные заголовки объектов, экономящие треть памяти.