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

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

1. Создаётся session, реализующий AutoCloseable: при закрытии он выбрасывает исключение с сообщением close.

2. Внутри блока try возникает исключение с сообщением send, поэтому выполнение блока прерывается.

3. Перед переходом к catch конструкция try с ресурсами автоматически закрывает session; закрытие тоже завершается исключением.

4. Поскольку основное исключение уже возникло в теле try, исключение закрытия добавляется в список подавленных исключений основного. Оно не заменяет причину сбоя отправки.

5. Обработчик catch получает основное исключение: первая строка вывода — send, вторая — 1, поскольку список подавленных исключений содержит один элемент.

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

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

Showboat и Rodney помогают показать работу ИИ-агента

Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.

uvx showboat --help

Эту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.

Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.

#ии #инструменты

Spring Boot Actuator: свои проверки здоровья и доступ к диагностике

В Spring Boot 4 проверки liveness и readiness включены по умолчанию. Первая показывает, нужен ли приложению перезапуск; вторая определяет, готово ли оно принимать трафик. По умолчанию они учитывают состояние запуска и остановки приложения, а дополнительные проверки можно включить в их группы.

В руководстве по настройке Actuator показано, как создать свой HealthIndicator, объединить проверки в группу и разрешить просмотр деталей только пользователям с ролью admin. Случайный статус в примере служит учебной демонстрацией, а не проверкой для рабочего сервиса.

Детали проверок могут раскрывать чувствительные сведения, например название используемой СУБД. Автор показывает, как скрыть их или ограничить доступ авторизованными пользователями.

#spring #java

Хаотичный планировщик помог найти ошибку в тесте JFR

В январском разборе Йоханнес Бехбергер исследовал JDK-8366486: тест CPU-time sampling обычно проходил, хотя после первой записи останавливал поток, создававший нагрузку.

Вторая запись могла получить событие от внутреннего потока JFR Periodic Tasks. Это маскировало ошибку самого теста. Успешный прогон ещё не означал, что проверяется нужный сценарий.

Автор использовал concurrency-fuzz-scheduler: написанный на Java прототип планировщика Linux меняет расписание потоков случайными паузами. С ним ошибочную ветку удалось воспроизвести быстрее, а исправленную — отдельно проверить повторными запусками.

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

Разбор Бехбергера и устройство теста

#java #jvm

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

1. Spring создаёт OrderService с областью singleton: этот экземпляр сервиса будет обслуживать оба запроса.

2. Для вызова конструктора Spring разрешает зависимость ReportBuilder и создаёт её экземпляр с областью prototype.

3. OrderService сохраняет полученную зависимость; обычное внедрение через конструктор выполняется при создании сервиса.

4. Первый запрос вызывает сервис, который использует внедрённый ReportBuilder.

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

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

Задача проверяет понимание областей действия компонентов и момента разрешения зависимостей в Spring. Если ReportBuilder хранит промежуточные данные отчёта, они могут сохраняться между запросами, несмотря на область prototype. Когда нужен новый экземпляр для каждой операции, сервис может явно получать его через ObjectProvider.