Java *

В статье разбираем практический маршрут на REST Assured 6.0.0 и JSON Schema: как закрыть структуру ответа одной проверкой, как сделать схему по-настоящему строгой и где в этой связке спрятан капкан, из-за которого схема с условной логикой выглядит рабочей, но не проверяет ничего.

ArrayList или LinkedList — классический вопрос по Java, на который до сих пор часто отвечают по учебнику, а не по результатам замеров.

Разбираемся, почему Big O не всегда совпадает с реальной производительностью, как кэши процессора ломают привычную логику и почему ИИ‑ассистенты повторяют ту же ошибку.

double быстрый, но хранит десятичные числа как двоичные приближения: 0.1 + 0.2 дает 0.30000000000000004. BigDecimal точен в десятичной арифметике, но дороже по памяти и CPU.

Выбор зависит от задачи: для метрик и ML хватит double с допуском, для налогов и счетов нужен BigDecimal с явным RoundingMode, для низкой latency - fixed-point на long.

Ошибка не в double или BigDecimal, а в выборе без понимания точности, округления и нагрузки. Подробнее - в новом переводе от команды Spring АйО.

Асинхронность NIO и асинхронность Kotlin: попробуем разобраться какие идеи заложены и как совместно использовать то и другое.

40-60% времени современных QA-команд тратится на диагностику сбоев в тестах. Эта проблема настолько серьёзна, что сейчас активно разрабатываются практики сокращения размеров тестовых сюит, Майкрософт рекомендует при триаже не разбирать каждое падение по отдельности, а кое-кто советует «стохастический подход» к разбору ошибок, при котором команды не тратят время на разбор каждого падения.

Если всё больше голосов говорят нам о том, что разбирать падения вручную становится слишком дорого, стоит задуматься об автоматизации. В этой статье я возьму тестовую сюиту средних размеров, попробую вначале пройти по результатам руками, а потом применю простейшее средство автоматизации: группировку результатов.

Ну что же…, на дворе 2026 год, первый DogPlanner живёт своей жизнью, доступен на многих площадках мобильных приложений, мы о нём много писали в соцсетях и различных блогах. С тех пор как мы сделали его, а опубликовали мы его аж в июне 2020 года, вы прислали нам много различных идей по его доработке, написали множество отзывов, а также мы узнали о приличном количестве проблемных мест по его функциональности и содержанию, и всё это было абсолютно заслуженно! Хотим сказать вам огромное спасибо за всю обратную связь, которую мы получили, и получаем до сих пор от вас! Но давайте снова вернёмся к критике…

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

Привет! Меня зовут Роман, я инженер данных в компании CDEK и занимаюсь разработкой платформы данных и внедрением self‑service инструментов. В этой статье расскажу, как мы обеспечиваем Event Sourcing подход в платформе больших данных, с какой болью столкнулись при переходе на Kafka 4.0 и как решились отказаться от JSON‑формата.

У нас есть процессы на бекенде, растянутые во времени. Для разбора инцидентов, сбоев и прочего мы прокидываем сквозные идентификаторы в логи. Мы можем увидеть логи конкретного процесса просто отфильтровав их по нужному значению поля такого идентификатора в логах. Таким образом мы видим все запросы, сообщения в кафку, информационные сообщения, если они случились в рамках нужного нам процесса, даже если он (процесс) был растянут во времени на несколько недель.

Это решение я упаковал open-source библиотеку, которой может воспользоваться каждый из вас после прочтения статьи.

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

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

Вторая — то, что мне приходилось тратить время, объясняя друзьям, как устроен мой код. Мне не нравилось, что я говорю отрывками, зависаю, не могу связать пары слов. Короче, тяжело донести мысль: сам прекрасно знаю, как оно работает, а нормально, быстро и чётко объяснить не могу.

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

На PreparedStatement обычно заканчивается вводный курс по JDBC / PostgreSQL. Все довольно просто, пока не задумываешься: а работает ли оно как надо в моем крутом инновационном приложении?

Дальше интереснее: как PostgreSQL выбирает custom или generic plan? кто именно кэширует statements? как с этим дружат ORM и внешние пулы?

По закону подлости все выясняется на собеседовании, в контексте “начальных банальных вопросов по БД”. Разберемся в подробностях и закроем эту тему

ПРЕКРАСНОЕ ДАЛЕКО

Мир цифровых технологий постоянно удивляет. Сначала появились супер процессоры с тактовой частотой аж 8 мегагерц (КР1810ВМ86М — до 8 МГц), затем память (К565РУ7 - Клон Intel 41256), удивляющая своими гигантскими объемами в 256 килобай при наборе из 8 штук. Казалось, мир сошел сума и достиг поистине фантастических возможностей. Но это было в далекие 90-е.

Вспоминаю как спустя пару лет впервые запустил установку своей Windows 95 ставя будильник на два часа позже, чтобы не пропустить фееричный запуск окончания установки на моем первом DX386 с 40 мегагерцами в турборежиме. Чуть позже написал своё первое приложение на Turbo Basic, размер которого составлял всего пару десятков килобайт. Славные были времена, ведь мне тогда было около 20-ти лет.

ВСЕ ВЫШЕ И ВЫШЕ

Время шло. Технологический прорыв казалось никак не мог затихнуть. Процессоры, память, интернет, все стремительно развивалось и уже никто не думал об ограничениях. Появились первые мессенджеры. ICQ со своим уникальным "ку-ку" звучал во всех офисах. Помню даже на некоторых фирмах штрафовали своих сотрудников за использовании мессенджера на рабочем компьютере. Появились первые программы по автоматизации финансовой деятельности предприятий. 1С-ку кажется уже знают все. Встроенный язык программирования, да ещё и с русским диалектом. Вау, вот времена наступили. Всё крутиться, сверкает и манит в магазин компьютерной техники прикупить очередную видюху с двумя или даже тремя куллерами. Эх, где же вы мои любимые Trident TVGA или Cirrus Logic с одним мегабайтов видеопамяти?

Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.

Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.

Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.

Spring Batch - проект в рамках экосистемы Spring Framework, который, как правило не получает должного внимания. Тем не менее, это хорошее решение для Enterprise Batch Processing.

Долгое время Spring Batch требовал SQL-базу для хранения общего состояния, шагов перехода, статусов выполнения и время запусков. Даже если проект жил на MongoDB, рядом часто приходилось держать Postgres или MySQL только ради метаданных.

В Spring Boot 4.1 стало проще: появился spring-boot-starter-batch-data-mongodb. Теперь Spring Batch научился работать с MongoDB.

В статье Josh Long рассказывает про новинки в рамках Spring Batch, в том числе и новую интеграцию с MongoDB, а также работу с GraalVM

В статье разбираем: как за пятнадцать минут превратить обычный метод с @McpTool в инструмент для модели, где проходит граница ответственности (решение принимает LLM — действует ваш код) и почему до прода доезжают единицы.

Xtunnel

xtunnel - российский туннель, который позиционирует себя аналогом ушедшего из России ngrok. Сегодня, работая над учебным проектом, я заметил за ним любопытное поведение. Например, мы ставим на логине токен как http only куку (ниже и дальше будет представлен код на Java Spring, но подобное поведение аналогично во всех языках):

Нормальные туннели не трогают такие куки, однако xtunnel такую куку закеширует (!) и будет подставлять ее в релеватные запросы по требованию кого угодно (!!). Например, в следующий метод, кто бы его не вызвал, xtunnel подставит куки последнего залогинного пользователя:

Таким образом, пользователи в обход логина могут представляться другими пользователями.

Java на бенчмарках обогнала Go при росте нагрузки: повтор эксперимента 2020 года в котором Mark Nelson и Peter Nagy сравнивали микросервисы на Go и Java на одном железе.

На маленьких нагрузках результаты совпадали.

В 2026-м повторили тест на актуальных версиях: Go 1.26, Oracle JDK 26, JDK с AOT-кэшем Leyden, Helidon SE 4.4 на virtual threads.

При лёгкой нагрузке Go и Java идут вровень.

При высокой нагрузке Java с Leyden AOT обгоняет Go почти вдвое.

Go не выиграл ни одного теста 2020 года. Leyden AOT — почти все.

Авторы подчёркивают: дело не в языке, а в том, что рантайм, фреймворк и настройки сети влияют сильнее, чем выбор языка.

24 февраля 2026 года в 16 часов по Хабаровскому времени в мессенджере MAX от аккаунты папы приходит сообщения вида "Посмотри, это ты на фото" и следующим сообщением приложен файл "Фото(3).apk". Я сразу же позвонил отцу - интернет отключили, симку вытащили, а на следующий день он сходил в МФЦ и поменял пароль. Файл с вирусом скачать я не смог - через полчаса после этого аккаунт отца удалили за спам, плюс само сообщение я удалил. Но пока файл ещё был я попросил брата переслать его мне, но скачать я его уже не мог - из-за удаления аккаунта.

Работу пояснительную хоть и проводили, но "был без очков, что-то тыкнул" и установил - когда у тебя телефон от Huawei без гугл сервисов, то все приложения плюс минус так и ставились. Прошло время - аккаунт через месяц папе дали вновь зарегистрировать, телефон тот мы отложили от греха подальше, выдал свой старый Samsung A50 и про случай забыли. Но одним вечером, когда я лежал в кровати я подумал - "Стоп, если аккаунт восстановили, то и файл я могу скачать?" Зашел в чат с братом, долистал до пересланного сообщения и решил скачать файл вновь. И что вы думаете - я его скачал! Б - Безопасность. А раз файл скачан, то надо его проанализировать - о чём и будет статья.

Совершенно точно каждый из нас (java-разработчиков), когда-либо встречал в своей жизни понятие "прокси" из Spring. Кто-то на уровне подготовки к собесам, а-ля "@Async создает прокси", а кто-то споткнувшись на self-invocation в собственном классе.

И большинство, собственно как и я до определенного момента, часто удовлетворяются простым объяснением: "Spring использует AOP, создает прокси вокруг нашего бина и тем самым добавляет дополнительную логику до и после вызова метода."

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

Сегодня мы разберемся:
Что такое этот $$SpringCGLIB$$0, который неожиданно оказался вместо моего класса? Кто и в какой момент решил заменить мой бин?
Откуда берутся загадочные Advisor и TransactionInterceptor, которые я никогда не создавал? Почему порядок выполнения аспектов именно такой?
И что вообще физически находится внутри этого самого Proxy?

Приглашаю Вас шаг за шагом проследить путь одного объекта: от обычного Java-бина до полностью собранного Spring Proxy. По дороге заглянуть в исходники Spring и посмотреть, как рождаются Advisor'ы, как они сортируются, кто собирает прокси и из каких объектов он на самом деле состоит.

Представьте: вы даёте задачу, а интеллект внутри IDE сам всё делает. Без интернета, без копилки токенов. Видит весь проект а не конкретный файл. Это уже реальность.

В чем отличие агента от чата - ассистента?
Всё просто они работают по схеме запрос-ответ. Спросил, получил текст и дальше сам разбирайся. А агент - это совершенно другая история. Агент сам планирует, что делать, сам использует инструменты (редактировать файлы, выполнять команды в терминале, искать по проекту), помнит весь контекст сессии и, что важно, умеет реагировать на ошибки и корректировать свои действия на ходу. Cline в IntelliJ именно такой. Он реально работает в вашей среде, почти как живой коллега.

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

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

У нас есть собственный GitHub Action, который блокирует PR в том случае, если суммарное количество измененных строк кода превышает 500.