Иногда этот вопрос можно встретить в форме задачи. Когда библиотека попадает в пользование широкого круга разработчиков, на её разработку фактически накладывается ограничение обратной совместимости. То есть, если в следующей версии вдруг пропадут используемые классы и их члены, разработчики не захотят обновляться. Тогда развитие библиотеки остановится.

Это масштабная и сложная проблема. В её решении помогает в первую очередь семантическое версионирование и механизм прекращения поддержки (deprecation).

В новой версии библиотеки некоторые компоненты API могут получать аннотацию @Deprecated. Функционально она не делает в программе ничего, но разработчик получит на этапе компиляции предупреждение: компонент устарел и не должен больше использоваться.

Ранее мы уже писали об особенностях использования @Deprecated. Собираясь удалить компонент API, нужно прежде отметить его @Deprecated(forRemoval=true).

Обычно разработчики библиотеки дают пользователю запас времени на миграцию. Они предоставляют Deprecation policy – документ, в котором дают обещание, сколько времени (или версий) после появления @Deprecated компонент всё еще не будет удален.

Для поиска в коде использования deprecated компонентов комплект JDK содержит утилиту jdeprscan. Утилита javadoc собирает список устаревших компонентов в отдельную страницу deprecated-list.html.