Иногда этот вопрос можно встретить в форме задачи. Когда библиотека попадает в пользование широкого круга разработчиков, на её разработку фактически накладывается ограничение обратной совместимости. То есть, если в следующей версии вдруг пропадут используемые классы и их члены, разработчики не захотят обновляться. Тогда развитие библиотеки остановится.
Это масштабная и сложная проблема. В её решении помогает в первую очередь семантическое версионирование и механизм прекращения поддержки (deprecation).
В новой версии библиотеки некоторые компоненты API могут получать аннотацию
@Deprecated. Функционально она не делает в программе ничего, но разработчик получит на этапе компиляции предупреждение: компонент устарел и не должен больше использоваться.Ранее мы уже писали об особенностях использования
@Deprecated. Собираясь удалить компонент API, нужно прежде отметить его @Deprecated(forRemoval=true).Обычно разработчики библиотеки дают пользователю запас времени на миграцию. Они предоставляют Deprecation policy – документ, в котором дают обещание, сколько времени (или версий) после появления
@Deprecated компонент всё еще не будет удален.Для поиска в коде использования deprecated компонентов комплект JDK содержит утилиту jdeprscan. Утилита
javadoc собирает список устаревших компонентов в отдельную страницу deprecated-list.html.👉@BookJava