В Java есть специальная аннотация @Deprecated для маркировки уставшего кода. С определенной периодичностью такой код из JDK удаляется. Обычно о конкретных сроках удаления анонс делается заранее и в теории можно успеть подготовиться, но на практике не все так просто.
В больших проектах найти куски устаревшего кода в куче зависимостей задача не тривиальная и требующая хорошей автоматизации. В этой ситуации к нам приходит на помощь новый тип события в JFR. Он был добавлен в JDK 22.
Давайте посмотрим на простом примере как это работает.
Для начала создадим простой класс и в его методе main вызовим любой @Deprecated метод. Для примера я выбрал конструктор класса java.net.URL(String). Со списком всех методов помеченных аннотацией @Deprecated вы можете ознакомиться по этой ссылке
public class App
{
    public static void main(String[] args) throws MalformedURLException {
        URL url = new URL("https://habr.com/ru/");
    }
}
Если вы попробуете скомпилировать его при помощи javac, то получите сообщение c предупреждением о том, что у вас в коде используется устаревший код.
~/IdeaProjects/Tests/src/main/java (master*) » javac App.java                                                                                                         user@user-home
Note: App.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Если добавить в параметры запуска еще и -Xlint:deprecation вывод станет чуть более информативен.
~/IdeaProjects/Tests/src/main/java (master*) » javac -Xlint:deprecation App.java                                                                                      user@user-home
App.java:8: warning: [deprecation] URL(String) in URL has been deprecated
        URL url = new URL("https://habr.com/ru/");
                  ^
1 warning
Но таким "дедовским" способом реальные проекты никто не собирает. Обычно используются инструменты автоматизирующие сборку. На данный момент довольно широко используются Maven и Gradle.
Если сделать простой Maven проект с таким pom.xml, то к удивлению мы не получим warning при компиляции того файла.
Hidden text
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.github.rodindenis</groupId>
    <artifactId>Tests</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <maven.compiler.source>22</maven.compiler.source>
        <maven.compiler.target>22</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
</project>
Для получегия таких warning нужно будет еще добавить параметр конфигурации showDeprecation для maven-compiler-plugin.
Hidden text
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.github.rodindenis</groupId>
    <artifactId>Tests</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <maven.compiler.source>22</maven.compiler.source>
        <maven.compiler.target>22</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
                <configuration>
                    <showDeprecation>true</showDeprecation>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>
Что будет если этот кусок кода уедет в библиотеку и мы с вами будем ее получать как уже скомпилированную зависимость? Ответ под спойлером.
Hidden text
Так как компилятор проверяет в момент компиляции, то соответственно warning в момент компиляции нашего кода мы не получим.
Давайте проверим? Я вынес вызов устаревшего кода в отдельный сабмодуль.
package com.github.rodindenis.jfr.event.lib;
import java.net.MalformedURLException;
import java.net.URL;
public class Printer {
    public static void print(String url) throws MalformedURLException {
        System.out.println(new URL(url).toString());
    }
}
Наш класс App тоже изменился
package com.github.rodindenis.jfr.event.main;
import com.github.rodindenis.jfr.event.lib.Printer;
import java.net.MalformedURLException;
public class App
{
    public static void main(String[] args) throws MalformedURLException {
        Printer.print("https://habr.com/ru/");
    }
}
Примеры pom.xml здесь не привожу. Их можно будет посмотреть в репозитории.
Как и ожидалось после компиляции класса Printer мы получаем warning, но вот когда мы уже подключаем уже скомпилированную библиотеку с этим классом как зависимость и пробуем скомпилировать App, то warning мы уже не ловим.
Для воспроизведения ситуации в скаченном из репозитория кода проведите следующие манипуляции. Сначала скомпилируйте и установитие все артефакты. На этом этапе вы увидите в логе warning при компиляции библиотеки.
mvn clean install
Так как у нас теперь локально установлена скомпилированная библиотека с кодом класса Printer, то мы можем попробовать отдельно перекомпилировать только основной код App. Эту команду выполняем только для сабмодуля main с классом App.
mvn clean package
И вот пришло время ощутить всю силу JFR.
Запускаем наше приложение с включенным JFR логированием в файл. Я перешел в каталог main/target своего проекта и из него выполнил команду
~/.jdks/temurin-22.0.2/bin/java -XX:StartFlightRecording:jdk.DeprecatedInvocation#level=all,filename=recording.jfr -cp ../../lib/target/lib-1.0-SNAPSHOT.jar:./main-1.0-SNAPSHOT.jar com.github.rodindenis.jfr.event.main.App
В текущем каталоге появился файл recording.jfr. Давайте посмотрим есть ли в нем нужное нам событие.
~/.jdks/temurin-22.0.2/bin/jfr print --events jdk.DeprecatedInvocation recording.jfr
В моем кейсе было напечатано
jdk.DeprecatedInvocation {
  startTime = 16:39:18.769 (2024-08-19)
  method = java.net.URL.<init>(String)
  invocationTime = 16:39:18.759 (2024-08-19)
  forRemoval = false
  stackTrace = [
    com.github.rodindenis.jfr.event.lib.Printer.print(String) line: 9
    ...
  ]
}
Важная оговорка. Данный подход позволит вам в рантайме выявить вызовы устаревшего кода, но если код не вызывается, то и события такого вы не получите.
          
 
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 позволит собирать такую информацию в том числе и для зависимостей в проекте.