Java *

В проде бывает так, что одна и та же операция часто повторяется: клиент не дождался ответа и ретраит, балансер порвал соединение, очередь переиграла сообщение. Вспоминаем про идемпотентность - это правило «повтор не должен создавать новый платёж/заказ».

Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности). Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке Idempotency-Key). Сервис сохраняет этот ключ у себя и связывает с результатом операции.

Далее приходит запрос с тем же ключом - сервис не выполняет бизнес-действие второй раз, а дедуплицирует на основе ключа идемпотентности. Но так ли всё просто? Многолетний опыт анализа инцидентов показал, что на практике большое количество систем всё же регулярно допускают дублирования, хотя делали всё по методичке.

В новом переводе от команды Spring АйО рассмотрим не самые очевидные ошибки и то, о чём стоит подумать, при реализации идемпотентного API.

Если вы следите за текущими тенденциями в мире найма/вакансий, то определенно заметили, что куда-то подевались вакансии Middle и Junior-разработчиков, и у этого есть несколько причин.

Первая: рынок просел, и общее количество вакансий в IT-индустрии сократилось. В результате Middle-позиции теперь можно закрывать Senior-разработчиками. Это уже случалось в нашей истории, но за любым спадом следует подъем.

Вторая — AI-агенты. Senior-разработчики получили "рычаг". Теперь задачи, которые ранее поручали Junior и Middle-разработчикам, можно поручить AI Agent. При этом для Senior мало что меняется, поскольку подробное review делать нужно в обоих случаях.

Можно сказать, рынок оказался в "клинче". Сейчас нет времени думать, что будет дальше, поскольку нужно решать текущие вопросы, а когда начнется подъем, нужного количества разработчиков может и не оказаться, поскольку они ушли в "плотники".

Однако сомневаюсь, что вас сильно волнуют проблемы рынка, разве что на кухне за чашкой кофе. А вот что делать конкретно сейчас и конкретно вам, чтобы стать Senior, разбираемся в статье...

UI‑тесты редко ломаются красиво: один редизайн формы — и локаторы приходится чинить по всему проекту.

В статье разберём, как собрать первый автотестовый проект на Java и Selenium с Page Object Pattern: куда класть страницы и компоненты, как писать базовый класс, почему лучше держаться за data-test и какие ошибки быстро превращают аккуратную архитектуру в набор хрупких обёрток.

На самом деле, JavaFX есть механизм кастомизации уже существующих компонентов (StackPane, Pane, HBox, VBox, ScrollPane и т.д.) с помощью css. css javafx поддерживает псевдоклассы (after, before, hover, focused, presed и так далее). В целом все гибко и можем довольно легко взять любой компонент и превратить его в свое родное.

Но возьмем к примеру задачу реализовать всплывающее окно подсказки. Я столкнулся с такой ситуацией и сначала подумал найти готовое решение но к сожалению не нашел что то более менее подходящей моей цели компонент, который был бы довольно простым для отображения и внутри производил бы расчетов размеров (Bounds). По этому было принято решение реализовать свой компонент тем более компонент редактора написан свой с рендером строк и частей.

Ваши UI‑автотесты снова «иногда падают», а команда уже привычно лечит это ретраями? Проблема может быть не в CI и не во фронтенде, а в том, что тест ждёт не то состояние интерфейса.

Разбираем пять ошибок в ожиданиях Selenium, из‑за которых автотесты превращаются в лотерею.

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

В статье разбираем, как спроектировать AI Gateway — инфраструктурный слой для централизованной маршрутизации, кеширования, лимитов, observability и отказоустойчивости при работе с AI‑моделями.

Каждый Java-объект в HotSpot начинается со служебного заголовка размером 12 байт. В JDK 27 по умолчанию он сжимается до 8 — это JEP 534, финальный шаг внедрения Compact Object Headers. Для типовых бэкендов это 5–15% экономии heap, для приложений с миллионами мелких объектов (особенно на Scala, Clojure и иммутабельных коллекциях) — до 30%, без изменений в прикладном коде.

Представьте, что вы работаете над кодом магазина, который живёт уже много лет. Бизнес доволен, продажи растут, но есть одна проблема — модуль обращения к весам превратился в чёрный ящик. Когда-то давно он работал прекрасно, но со временем разросся. Многопоточность, низкоуровневый код и бизнес-логика сплелись в один клубок, каждое изменение могло что-то сломать. И так дошло до того, что появились несколько фич, которые не реализовывались уже полгода... Стало ясно, что требуется не столько рефакторинг, сколько новая, удобная для работы абстракция.

Приветствую! Меня зовут Иван Матвеев, я разработчик в компании X5, и сегодня я расскажу, как мы начали рефакторить наши весы.

Каждый процесс в вашей компании — наследие прошлого. Жёстко? Возможно. Но логика верна. Каждый бизнес-процесс, который ваша организация выполняет сегодня, был спроектирован для мира без ИИ. Всё — от цепочек согласований до последовательностей передачи задач и обработки исключений — было построено на человеческом суждении. И всё это было выстроено вокруг предположения, что программное обеспечение может автоматизировать задачи, но координировать работу будут люди. Это предположение больше не работает.

После выхода Claude Opus 4.7 стало очевидно, что агент технически быстрее меня. А 28 мая Anthropic выпустила Opus 4.8 с теми же ценами, заметно лучшим coding/agentic-скором и новой возможностью держать в голове миграции на сотни тысяч строк

Знает он, кажется, всё. Все фреймворки, все паттерны, всю историю последних пятнадцати лет на StackOverflow и GitHub. По объёму знаний это легко сеньор, местами принципал

Но при всём этом ему не хватает трёх вещей

В новом переводе от команды Spring АйО рассмотрим ленивую инициализацию в Java , которая почти всегда значит: поле сначала null, потом double-checked locking, volatile, синхронизация. Ошибиться легко, а final не поставить. Итог - код хрупче и JVM хуже делает constant folding.

В JDK 26 (preview, JEP 526) добавили LazyConstant<T>: final поле, рецепт вычисления через Supplier, значение доступно черезget(). Supplier выполнится при первом get и только один раз успешно, даже при гонке потоков. Кроме этого значение помечается как @Stable - JVM может считать его константой и агрессивнее оптимизировать.

Граничные случаи: null нельзя; не сериализуется; исключение из Supplier пробросится и следующая попытка снова пересчитает; equals у LazyConstant - только identity.

Для 1:n есть List.ofLazy и Map.ofLazy: элементы/значения считаются по индексу/ключу по требованию и кэшируются.

В проде connection pool редко падает громко — чаще он тихо превращает сервис в очередь ожидания: запросы висят, база задыхается, Kubernetes начинает перезапускать поды, а в логах всплывает знакомое Connection is not available.

В этой статье разбираем пять настроек HikariCP, которые чаще всего крутят «на глаз»: размер пула, minimumIdle, maxLifetime, keepaliveTime и connectionTimeout. Покажем, почему «поставить побольше» почти всегда плохая идея, как таймауты инфраструктуры ломают соединения и какие метрики стоит вывести в Grafana, чтобы увидеть проблему до инцидента.

Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными разработчиками !

Java Telegram API обманывает разработчиков дубликатами запросов при отключении интернета?

Мы команда разработки телеграмм ботов, которая смогла придумать решение для работы с дубликатами в Statefull командах Telegram API используя REST. Прошли путь от наивного решения до работающего продукта.

Статья о том как Я начал разработку собственной Idea и чуть не бросил 2 раза эту затею. Как я выбрал неподходящий готовый пакет редактора кода, и начал разработку своего снова.

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

Меня зовут Михаил Поливаха. Я думаю, что в Хабе Spring АйО меня уже относительно знают. В рамках Spring АйО мы довольно часто занимаемся подбором технического материала и его ревью. Сам же я довольно регулярно выступаю на конференциях, контрибьючу в Open Source и т.д.

Также, часто наши материалы крутятся вокруг Java разработки и конечно же Spring-а. И данной пост, хоть и будет с одной стороны сильно связан с Java и Spring Framework, но, тем не менее, не похож на остальные.

На днях произошло довольно знаковое событие. Мы с небольшой командой примерно год писали инструмент, который призван существенно упростить весь процесс отладки, тестирования и мониторинга Spring Boot приложений в production. И вот этот проект наконец-то получил первый Milestone Релиз.

Проект называется Axelix.

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится?

В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking.

Откуда берётся «среднее приложение с GitHub»? Если попросить агента создать JPA‑сущность или настроить Spring Security, то он выдаст вполне рабочий код. Вопрос только в одном: для какого проекта?

Модели натренированы на миллионах репозиториев: студенческие работы, всех задолбавшая Petclinic, туториалы с YouTube, у меня кстати, есть куча своих:D.

Но без чёткого контекста агент выдаёт типичное «среднее приложение с GitHub»: всё синтаксически верно, но далеко не всегда вписывается в существующий РЕАЛЬНЫЙ проект. С Lombok или без него? Используя @IdClass или @EmbeddedId? Предпочитаешь Record'ы или классические классы? Как у тебя маппятся DTO? Агент этого не знает и чаще всего либо пытается угадать, либо начинает грепать всё что можно и нельзя.

Prompt engineering помогает, но ненадолго. Прикреплять каждый раз примеры сущностей и архитектурные правила — прошлый век. Интеграция в IDE с @ и выбором файлов уже лучше, но всё равно надо постоянно об этом помнить и как РОБОТ писать ему одно и тоже.

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

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

В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

Микросервисы обещают масштабирование и независимость команд, но чаще ломают систему медленнее монолита. Почему?

В статье разбираем семь архитектурных ошибок, которые можно встретить в реальных системах: выбор по моде, shared database, игнорирование network latency, операционная сложность на потом, слишком мелкая декомпозиция, отсутствие стратегии consistency, недооценка сроков миграции.