Зачем включать методы в открытый API, такой как Thread.destroy (), которые не реализованы?

Question

Я немного озадачен этим.В Java API есть несколько методов, таких как Thread.destroy(), которые вообще не реализованы.(Я знаю, что это не было реализовано, вероятно, потому что это было бы склонно к тупику, но это не то, к чему я стремлюсь.) Если это не реализовано, то зачем вообще включать его в публичный API?Это просто бесполезный метод, который люди могут вызвать, чтобы вызвать исключение во время выполнения.

Я вижу смысл в подобных вещах, когда вы реализуете интерфейс, а конкретная реализация не реализует все методыпо той или иной причине.Но с потоком дело обстоит иначе.

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

Может ли кто-нибудь еще пролить свет на этот вопрос?

Исходя из этого, поскольку он не реализован, почему неони удаляют это?Я знаю, что с обратной совместимостью Java есть все дело, но поскольку нет кода, который мог бы вызвать этот метод и когда-либо работать во время выполнения, конечно, это не нарушение взлома кода?Или тот факт, что он мог компилироваться раньше, а теперь не может сосчитать (даже если он не может скомпилировать что-либо значимое?)

Answer 1

Документация для Thread.destroy () ссылается на причины устаревания методов Thread. Любопытно, что ссылка гласит:

В настоящее время мы не внедряем это, но и не осуждающий это

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

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

Answer 2

Вы читали документы для него?

Этот метод был первоначально разработан, чтобы уничтожить эту тему без каких-либо очистки. Любые мониторы, которые он держал, остались бы заблокированными. Тем не менее метод никогда не был реализован. Если бы это было осуществлено, это было бы быть склонным к тупикам во многом манере приостановить (). Если цель поток удерживал блокировку, защищающую критический системный ресурс, когда он был уничтожен, ни один поток не сможет снова получить доступ к этому ресурсу. Если другой Поток когда-либо пытался заблокировать этот ресурс, в результате возникнет взаимоблокировка. Такие тупики обычно проявляются как «замороженные» процессы. Для получения дополнительной информации см. Почему Thread.stop, Thread.suspend и Thread.resume Устаревший?.

Кроме того, из «Устаревание Java-потока» (ссылка сверху):

Thread.destroy никогда не был реализован. Если бы это было реализовано, это будет склонен к тупику в порядке Thread.suspend. (На самом деле это примерно эквивалентно Thread.suspend без возможности последующий Thread.resume.) В настоящее время мы не реализуем его, но мы не осуждаем его (опережая его реализацию в будущее). В то время как это, конечно, было бы склонно к тупику, это было утверждал, что могут быть обстоятельства, когда программа готова рискуйте в тупик, а не выходите прямо.