Один экран в приложении, а на бэкенде несколько REST-вызовов, куча эндпоинтов и ответы, где 90% полей не используются. Теряем в скорости, усложняется фронтенд и приходится версионировать контракт, когда меняется формат данных.

GraphQL предлагает другой подход: один API-эндпоинт и запрос, в котором клиент сам указывает, какие поля ему нужны. Это снижает overfetching, уменьшает количество сетевых затрат и упрощает договоренности между фронтом и бэком за счет схемы как явного контракта и живой документации.

В новом переводе от команды Spring АйО разберем, где GraphQL реально помогает: как уйти от разрастания эндпоинтов, как держать контракт синхронизированным и что делать с типичными проблемами производительности и наблюдаемости, когда данные собираются из разных источников.

Данная статья является переводом анонса Гевина Кингa о релизе первого milestone JPA 4 спецификации и общего вектора развития JPA.

Полноценная 4-ая версия JPA спецификации должна выйти чуть-чуть позже в этом году. Тем не менее, то, что сейчас в Milestone это основа, которая, возможно, с небольшими доработками, но уже пойдёт в релиз в этом году.

От себя скажу, что данное обновление будет довольно крупное. Я оставил свои комментарии там, где посчитал уместным.

P.S: У нас в рамках Spring АйО Академии как раз есть программа посвящённая Hibernate. В ней мы тоже затронем новую версию спецификации, в частности и работу со StatelessSession и EntityAgent на практике. Я думаю, что из всего апдейта, именно стандартизация работы без Persistence Context будет самым важным для прикладных разработчиков. Остальное тоже важно, но не так как работа с EntityAgent.

Приятного чтения!

В новом переводе от команды Spring АйО рассмотрим утечки памяти в Java.

Не секрет, что GC освобождает только недостижимые объекты. Утечка в Java начинается там, где объект уже не нужен, но на него все еще есть цепочка ссылок от живого потока.

Симптомы обычно одинаковые: куча растет, GC срабатывает чаще, паузы увеличиваются, финал - java.lang.OutOfMemoryError: Java heap space.

В целом вывод такой, что нужно смотреть график heap в VisualVM/JVisualVM/JConsole, снимать heap dump (jmap), в Eclipse MAT запускать Leak Suspects и проверять цепочки удерживающих ссылок.

Я уже давно хотел на этот счет написать статью. Она короткая, но имхо она нужна.

Давайте с места в карьер: merge в Hibernate это не универсальный save, и чаще всего он Вам не нужен.

На самом деле, если абстрагироваться, то это специализированная операция для случая, когда у вас есть detached-сущность, и вы хотите перенести ее состояние в текущий Persistence Context.

Проблема в том, что на практике merge очень часто используют для апдейта любой сущности (Spring Data JPA иногда так делает) и как следствие получают лишние SQL-запросы.

Ниже разберем на мой взгляд главное - почему именно так происходит, где merge действительно нужен, а где он превращается в антипаттерн (P.S да почти везде).

В новом переводе от команды Spring АйО разберем тему раздувания памяти в JDK 17. Апгрейд микросервисов с JDK 8 на JDK 17 прошел dev и QA спокойно, но в проде через 2-3 часа все начало падать. Утилизация памяти выросла в 4 раза, контейнеры стали ловить OOMKill и перезапускаться, Uptime SLA просел, массовый инцидент.

Раньше JVM использовала около 50% памяти контейнера и обслуживала ~400 потоков. После релиза стало 95-100% и 1600+ соответственно. 

При этом heap выглядел нормально, около Xmx, а раздувалась нативная память: ~800 MB -> 3,4-3,6 GB. Виноваты несколько эффектов, которые в контейнерах усиливаются: JVM начала создавать намного больше потоков, OS стала выделять JVM гораздо больше, а дефолтный GC в JDK 17 добавил накладные расходы.

Всё это из-за простого бага в JDK, который при миграции утащил за собой весь production.

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д.

Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью.

В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах.

Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC.

В новом переводе от команды Spring АйО смотрим, как подружить современный Spring Boot и OpenTelemetry так, чтобы данные уходили по OTLP в любой совместимый бэкенд. 

В экосистеме Spring большая часть телеметрии была завязана на Micrometer Project (Был ещё spring-cloud-sleuth если кто помнит). Но полноценного all-in-one решения для того, чтобы Spring Boot приложение просто начало экспортировать телеметрию по OTLP не было. До Spring Boot 4.

На данный момент для интеграции OTel в Spring Boot приложения есть 3 пути: Java Agent (минимум кода, но чувствителен к версиям и может конфликтовать с другими агентами), сторонний OTel starter (стартер от самих OpenTelemetry, но тянет alpha-зависимости) и новый spring-boot-starter-opentelemetry, доступный в Spring Boot 4.0. Про него и будет речь.

Bearer-токен работает слишком просто: кто его получил, тот и авторизован. Именно поэтому утечки токенов регулярно превращаются в реальные инциденты — от CI/CD до облачных хранилищ.

В новом переводе от команды Spring АйО рассмотрим, как DPoP меняет эту модель, привязывая токен к ключу клиента, зачем это нужно backend-разработчику и как поднять рабочую реализацию на Keycloak и Quarkus.

В новом переводе от команды Spring АйО разберем, почему stringly-typed API со временем становятся хрупкими, чем помогают метамодели вроде Querydsl и JPA Criteria, и как новый механизм в Spring Data даёт более лёгкую и естественную альтернативу без лишней инфраструктуры сборки.

Иногда одна незаметная фича может сжигать гигантский объём ресурсов. В Netflix именно так и вышло: скоринг серендипности в Ranker оказался дорогой горячей точкой, а попытка слегка его ускорить в итоге привела к большой инженерной перестройке — от батчинга до SIMD через JDK Vector API.

В новом переводе от команды Spring АйО разберем, как SIMD AVX инструкции на практике позволили снизить потребление CPU.

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

Подробнее в новом переводе от команды Spring АйО.

JDK 26 выходит уже совсем скоро. Тем временем в GC закрыли около 380 задач (почти в 2 раза больше, чем в прошлом релизе), но в этот раз акцент сместился с  больших фич в пользу практичных доработок.

Главное для всех сборщиков: нормальный учет CPU GC. Теперь считают не только stop-the-world паузы, но и конкурентную работу и дедупликацию строк. Можно посмотреть через лог cpu=info при завершении VM, обновили Hsperf-счетчики, есть доступ из кода. Плюс новый JFR-ивент с деталями по string dedup.

JEP 516: Aot Cache стал независим от выбранного GC и опций VM. Включение через опцию -XX:+AOTStreamableObjects.

G1 получил самые заметные улучшения: JEP 522 уменьшает синхронизацию между GC и приложением (цель - увеличить throughput). Еще: целевое использование CPU G1 по умолчанию снижено с 8% до 4%, добавили важнейший флаг UseGCOverheadLimit.

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

С появлением ИИ-агентов процесс разработки начинает радикально меняться — от написания кода вручную к генерации систем по подробной спецификации. Это поднимает неожиданный юридический вопрос: насколько вообще защищает авторское право, если систему можно заново реализовать по её архитектурному описанию. Раньше подобная clean-room реализация требовала большой команды инженеров, но теперь её может провести один человек с помощью нескольких ИИ-агентов. На этом фоне возникает ощущение, что классические open-source лицензии защищают код, но почти не защищают саму систему как идею.

Почему одни системы всегда показывают актуальные данные, а другие — иногда отдают устаревшее, но зато хорошо масштабируются и показывают хорошие показатели по производительности?

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

Cursor теперь доступен в IntelliJ IDEA, PyCharm, WebStorm и других IDE JetBrains через протокол Agent Client Protocol (ACP).

Разработчики, которые полагаются на IntelliJ IDEA и другие IDE JetBrains за их мощную поддержку Java и нескольких языков, теперь могут использовать любую передовую модель вместе с Cursor для агентно-ориентированной разработки. Подробнее - в новом переводе от команды Spring АйО.

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена.

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

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

Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах.

Подробнее - в новом переводе от команды Spring АйО.

Параллельные стримы в Java 8 выглядят как бесплатное ускорение: добавил .parallel() — и все ядра побежали работать. Но по факту всё сложнее, так как распараллеливание имеет накладные расходы, зависит от того, насколько хорошо делится источник данных, сколько стоит объединение результатов, и даже от локальности данных в памяти.

В новом переводе от команды Spring АйО на примерах и бенчмарках разберем, почему простая свёртка на маленьких диапазонах может стать медленнее, почему ArrayList часто выигрывает у LinkedList в параллели, как reduce может неожиданно сломаться из-за неверного identity, и что вообще происходит внутри common ForkJoinPool.

JVM в первую очередь процесс операционной системы. Но важно понимать, что требования к этому процессу на production отличатся от требований на workstation-е разработчика. 

Если для разработчику важно, чтобы IDE работала быстро и не потребляла всю возможную память на машине, то для серверных JVM важно потреблять максимальный предоставленный ресурс и работать предельно быстро.

В новом переводе от команды Spring АйО разберем, какие существуют базовые настройки кучи, GC и CPU помогают синхронизировать JVM с лимитами контейнера и не переплачивать за простаивающие ресурсы.

В одном и том же null часто прячут разные смыслы: “нет значения”, “неизвестно”, “неинициализировано”. Потом это всплывает в NPE и в кривой логике исполнения.

В Ceylon эту проблему решают через типовую систему, через Union типы. Подробнее, в переводе от Spring АйО.