Когда методы API, помеченные как «устаревшие», действительно исчезнут?

Question

Я проверяю изменения, внесенные одним из моих коллег, и он добавил несколько вызовов к Date.toMonth(), Date.toYear() и другим устаревшим Date методам. Все эти методы устарели в JDK 1.1, но он настаивает на том, что их можно использовать, потому что они еще не исчезли (мы используем JDK 1.5), и я говорю, что они могут уйти в любой день, и ему следует Calendar методы.

Сказал ли Sun / Oracle на самом деле, когда эти вещи уходят, или @deprecated означает, что вы теряете очки стиля?

Answer 1

Что касается API, ... не указано, что они будут удалены в ближайшее время.

Несовместимости в J2SE 5.0 (начиная с 1.4.2) :

Совместимость с источниками

[...]
В целом, политика следующая, за исключением любых несовместимостей, перечисленных ниже:

Устаревшие API - это интерфейсы, которые поддерживаются только для обратной совместимости. Компилятор javac генерирует предупреждающее сообщение всякий раз, когда используется один из них, если не используется параметр командной строки -nowarn. Рекомендуется изменить программы, чтобы исключить использование устаревших API, , хотя в настоящее время нет планов по удалению таких API - за исключением JVMDI и JVMPI - полностью из системы.

Даже в его Как и когда следует устаревать API , ничего не говорится о политике, касающейся фактически удаления удаленных API ...

---

Обновление 10 лет спустя, новый JDK9 + Расширенный износ уточняет политику амортизации.
См. Jens Bannmann answer для более подробной информации.
Это также подробно описано в этом сообщении в блоге Vojtěch Růžička , после критики в отношении JEP 277 .

Соглашение для JDK заключается в том, что как только API JDK будет помечен как forRemoval=true в определенной версии Java, будет удалено в следующем основном выпуске Java .
Это означает, что когда что-то помечено как forRemoval=true в Java 9, оно должно быть полностью удалено в Java 10.
Помните об этом при использовании API, помеченного для удаления.

Обратите внимание, что это соглашение применяется только к самому JDK, и сторонние библиотеки могут свободно выбирать любое соглашение, которое они считают подходящим.

Answer 2

Они не уходят. Тем не менее, они обычно устарели, потому что а) они опасны, в отличие от Thread.stop () или б), есть лучший или, по крайней мере, более приемлемый способ сделать это. Обычно устаревший метод javadoc подскажет вам, как лучше. В вашем случае, Календарь - рекомендуемый способ сделать это.

Хотя вполне возможно, что они будут удалены в будущем, я бы на это не ставил. Однако, если кто-то разветвляется на Java, он, вероятно, первым сделает это ...

Answer 3

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

Answer 4

ТЛ; др

Начиная с JDK 10 , все оригинальные методы java.util.Date все еще существуют, но эти и другие API теперь могут быть явно помечены для удаления. Другие API были недавно удалены.

Полный ответ

До Java 9 ни один устаревший API в JDK никогда не удалялся (см. 20 лет устаревания Java ).

Однако, как часть функции, называемой Enhanced Deprecation , JDK 9 ввел флаг @Deprecated(forRemoval=true) и добавил его к десяткам ранее устаревших API . java.util.Date методов среди них не было.

Кроме того, впервые в истории языка JDK 9 удалил ранее устаревших API (как описано в Спецификация Java SE 9 ). Они были препятствием для модульности и были объявлены устаревшими в JDK 8.

JDK 10 помечены более устаревшие API для удаления . Еще раз, java.util.Date методы были сэкономлены.

JDK 10 также удалено некоторые устаревшие API для удаления в классах SecurityManager и Runtime (как описано в Спецификация Java SE 10 ).

Итак, вынос:

1. Устаревшие для удаления API, скорее всего, будут удалены в ближайшее время. Примите это всерьез. Хотя их нельзя удалить в выпуске после отметки forRemoval (например, Thread.stop(), отмеченной в JDK 9, но оставшейся в JDK 10), это может произойти быстро.
2. Ни один устаревший API не является безопасным, поскольку даже давно устаревшие API можно было удалить довольно быстро: один выпуск JDK устанавливает флаг forRemoval, а следующий удаляет API. Например, API, которые были удалены с помощью JDK 10, устарели в течение как минимум 20 лет (начиная с JDK 1.2), так долго, что некоторые люди теперь могут быть удивлены.
3. С новым циклом выпуска Oracle релизы JDK и, соответственно, устаревание и удаление происходят намного быстрее.

Answer 5

Ну, «еще не ушел» и «никогда не уйду» - это две разные вещи. Вот и весь смысл амортизации. Они могут уйти с любым будущим выпуском. Их использование на ваше усмотрение. Просто знайте, что в будущем выпуске JDK ваш код может оказаться в непригодном для использования состоянии.

Answer 6

У меня есть лучшая рекомендация: вместо того, чтобы указывать ему использовать Calendar, вы должны переключиться на JodaTime или JSR-310 предварительную версию. Некоторые методы java.util.Date могут быть устаревшими, но, по моему мнению, весь класс должен быть устаревшим, наряду с Calendar. Разработчики JSR-310, похоже, согласны, хотя я сомневаюсь, что они когда-нибудь укусят пулю и осудят ее.

В произвольном порядке, вот что не так с Date:

• Его внутреннее представление составляет миллисекунды с начала эпохи; следовательно, не может представлять даты до эпохи.

• Все его полезные методы (например, toString) сначала нормализуют дату в соответствии с местным часовым поясом. При работе с экземплярами UTC Date это может действительно раздражать; Вы вынуждены использовать Calendar или вы будете делать очень плохие ошибки.

• Calendar. Это просто воняет. Может выиграть награду за худший API когда-либо.

• Всегда представляет мгновенное время . Нет способа представлять конкретные дни или конкретные годы. Невозможно представить значения дат без часового пояса.

• Практически не имеет полезных методов. Смотрите, например Свободный интерфейс JodaTime для арифметики дат.

• Должен быть назван Datetime, учитывая, что он один.

Answer 7

Устаревшие функции, которые заменены, и их следует избегать. Несмотря на то, что они остаются в JDK, они не одобряются, так как существуют лучшие методы. Методы оставлены в API для поддержки обратной совместимости, но их, как правило, следует избегать, так как они могут быть удалены в будущих версиях API.

Технически нормально использовать устаревшие методы, но, как правило, причина, по которой он устарел в первую очередь, заключалась в том, что был разработан лучший / более быстрый / более чистый API.

Answer 8

Если устаревшие методы исчезнут, они могут сломать существующий код.

Хотя поддержание чистого API важно, но устаревшие методы никому не мешают. Конечно, теперь есть лучшие способы сделать что-то новое, поэтому новые методы заменяют старые. Но не было бы никакой выгоды (кроме более чистого API), избавляясь от старых.

Думайте о "устаревшем" как о значении "устаревший", но не обязательно "на разделочной доске".

Answer 9

Я определенно видел, как устаревшие функции уходят - от старых версий Java до текущей (я начал на 1.1, а некоторые вещи явно НЕ РАБОТАЛИ в 1.4).

Другие языки по-разному относятся к устареванию - в прошлом было известно, что Python, например, удаляет устаревшую функциональность только после выпуска или двух.

Answer 10

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

Но устаревшие методы могут исчезнуть в любое время в будущем и, как правило, не рекомендуются по какой-либо причине - либо потому, что они ненадежны, либо имеют неприятные побочные эффекты, либо просто потому, что есть или более элегантный способ делать вещи. В JavaDoc для метода обычно подробно описывается, какой из них имеет место, и каков приемлемый способ выполнения той же операции в наши дни. Довольно часто устаревший метод заменяется реализацией, которая в любом случае вызывает «правильный» метод, так что вы все равно просто добавляете уровень косвенности.

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