Новое событие в JFR для диагностики использования устаревшего (deprecated) кода

[novoselov]

Что будет если этот кусок кода уедет в библиотеку и мы с вами будем ее получать как уже скомпилированную зависимость?

А можно просто падать при warning'ах и такой код не будет компилироваться.

<failOnWarning>true</failOnWarning>

[c0d3_r3d]

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

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

Новое событие в JFR начиная с JDK22 решает эту задачу, но опять же частично. Мы можем отлавливать использование такого кода в рантайме.

[Antgor]

Падать при компиляции - это безумие. Ну если это pet-проект, то наверное да. Но Deprecated может висеть годами и десятилетиями. Например Thread.stop() и еще несколько методов ушли в Deprecated в Java 1.2 !!! 26 лет назад. И до сих пор висит со статусом "Deprecated, for removal: This API element is subject to removal in a future version."

А вот собирать в рантайме через JFR и рефакторить по мере обнаружения - очень правильный путь.

[c0d3_r3d]

Согласен.

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

Новое событие в JFR позволит собирать такую информацию в том числе и для зависимостей в проекте.