Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

Хотя можно предположить, что они будут удалены в какой-то момент в будущем, я бы не стал делать ставку на него. Если кто-нибудь когда-нибудь откроет Java, они, вероятно, будут первым делом...

Ответ 3

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

Ответ 4

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

Ответ 5

ТЛ; др

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

Полный ответ

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

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

Ответ 6

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

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

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

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

• Calendar. Он просто воняет. Возможно выиграть награду за худший API.

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

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