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