Телеграм канал «Чашечка Java»

Маршрутизатор запросов к моделям на Spring AI TypeSafe

Spring Boot 4.1.1 и стартер Spring AI TypeSafe 0.1.0: в туториале запрос сначала получает оценку сложности, затем направляется к выбранной модели. Приветствие и задача по проектированию архитектуры могут требовать разных моделей.

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

Для маршрутизатора достаточно стартера. Без свойства spring.ai.typesafe.api-key он не создаст бин TypeSafeClient. Проект пока находится в Spring AI Community и не входит в основной репозиторий Spring AI.

#spring #java

Spring Boot 4: настройка сервера авторизации и проверка токенов

Spring Authorization Server вошёл в Spring Security 7 и следует его циклу релизов. Он выдаёт клиентским приложениям токены доступа по OAuth 2.1 и поддерживает OpenID Connect 1.0 для идентификации пользователей.

В руководстве по настройке сервера показаны регистрация клиента через свойства приложения и проверка токенов в HTTP-клиенте IntelliJ. Authorization Code разбирается на примере входа пользователя с подтверждением разрешений. Client Credentials используется для обмена между приложениями без участия пользователя. Затем автор добавляет в JWT, токен с полями данных, список полномочий под именем aut.

Пример хранит пользователей в памяти. Для промышленной эксплуатации автор рекомендует внешний сервис управления пользователями и входом, например Keycloak или Okta.

#spring #java

JDK 28: маленькие аллокации Arena.ofConfined() станут дешевле

Для будущего JDK 28 подготовили оптимизацию FFM API: небольшие выделения нативной памяти в Arena.ofConfined() смогут обслуживаться из переиспользуемых пулов. По умолчанию кэш платформенного потока хранит до четырёх пулов по 64 байта.

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

Оптимизация работает и с виртуальными потоками: пул берётся у несущего потока и затем принадлежит арене. Переписывать вызовы API не требуется. Выигрыш в JMH измерен для маленьких аллокаций; ускорение всего приложения зависит от его нагрузки.

Устройство пулов и результаты замеров

JDK 28: простой API для чтения и создания JSON

Для JDK 28 интегрировали JEP 540: модуль jdk.incubator.json позволит работать с JSON без внешней библиотеки. Метод Json.parse() строит дерево JsonValue, по которому можно переходить через get() и извлекать значения нужного типа.

Такой API пригодится, например, для разбора ответа REST-сервиса или создания небольшого JSON-документа в утилите. Область задач ограничена: автоматического преобразования Java-объектов в JSON и потокового разбора в нём нет.

API находится в стадии инкубации, а JDK 28 доступен в ранних сборках. Для существующего приложения на Jackson переход потребует оценки того, какие возможности оно использует.

Описание и примеры JEP 540

Развёрнутое пояснение:

1. При построении дерева зависимостей Maven обнаруживает core:1.4 через client: от приложения до этой зависимости два перехода.

2. Через adapter и bridge обнаруживается core:2.0: до неё три перехода.

3. Поскольку groupId и artifactId совпадают, Maven рассматривает эти зависимости как две версии одного артефакта и разрешает конфликт по правилу ближайшей зависимости.

4. Путь до core:1.4 короче, поэтому в путь классов попадает только версия 1.4. Более высокий номер версии не даёт приоритета, а сам конфликт версий обычно не прерывает сборку.

Почему это важно

Задача проверяет разрешение транзитивных зависимостей Maven. При добавлении библиотеки приложение может получить более старую версию общего артефакта, чем ожидает другой компонент. Если ему нужны методы из версии 2.0, во время выполнения возможен NoSuchMethodError. Дерево зависимостей помогает обнаружить такой выбор, а управление версиями — задать согласованную версию явно.

Почему нагрузочный тест в одной JVM может скрыть задержки GC

Если генератор запросов работает в той же JVM, что и тестируемый сервис, пауза GC останавливает оба компонента. Пока сервис не отвечает, генератор тоже не создаёт часть запросов. В измерения не попадает нагрузка, которая пришла бы от независимого клиента.

Исследователи сравнили режимы SPECjbb2015 на OpenJDK 27: с генератором внутри JVM сервиса и в отдельном процессе. Для сборщиков с заметными паузами значения p99 существенно различались; у ZGC такой разницы не наблюдали.

Даже учёт запланированного времени отправки не восстанавливает запросы, которые генератор не смог создать. При проверке хвоста задержек полезно вынести его в отдельную JVM и сопоставить времена запросов с логами GC.

Методика и экспериментальные результаты