Знищене порівняно з денігрованим у JavaDoc?

11

У JavaDoc для X509Certificate getSubjectDN()нього зазначено:

Денігровано , замінено на getSubjectX500Principal ().

Я звик бачити застаріле в методах для методів, які більше не слід використовувати, але не денігрувати. Я знайшов повідомлення про помилку щодо цього конкретного випадку, коли його було закрито коментарем:

Це не помилка. "Зневищений" призначений для вживання лише у серйозних випадках.

Коли ми використовуємо метод, який застарів , загальною запропонованою дією є припинення використання методу.

Отже, що є запропонованою дією, коли метод позначений як Денігрований ?

java terminology javadocs

— Джейкоб Шоен
джерело

2

Ого. Я прочитав відповіді, і хоча я впевнений, що вони технічно правильні, "Деніґрація" - це жахливе слово. Вони повинні були просто використати "Відмовляти". Не потрібно плювати на код; попередження буде достатньо.

— Ерік Кінг

@Eric King I якось почувався. Я більше думав по принципу, що, якщо це не відштовхується, просто зневажте це.

— Джейкоб Шоен

9

Визначення мерріам-Вебстера деграграту пропонує:

1: нападати на репутацію: ганьбити <принижувати противників>
2: заперечувати важливість чи обгрунтованість: принижувати < принижувати їхні досягнення>

На підставі того , що написано в інших пов'язаних помилок, зганьбити применшує / з'являється , щоб відповідати Намір формулювань , які використовуються в Javadocs - Bug ID: 4959744 очорнити X509Certificate.getSubjectDN () і співробітництво :

Методи getSubjectDN () і getIssuerDN () в X509Certificate і getIssuerDN () в X509CRL є проблематичними . Вони повертають не визначений клас, що реалізує інтерфейс java.security.Principal, який має дуже вільну специфікацію.

Оскільки ніяких додаткових специфікацій у методах getSubjectDN () та getIssuerDN () немає, реалізаціям може бути повернуто довільний, конкретний для реалізації клас. Досвід реального світу показав, що це так, що призводить до непереносимості або ненадійності коду. З міркувань сумісності специфікації цих методів неможливо змінити, і їх слід вважати недоступними.

Методи заміни getSubjectX500Principal () & co, які повертають екземпляр чітко визначеного класу X500Principal, були додані в JDK 1.4. Реалізація цих методів була розроблена, щоб уникнути всіх подібних проблем. Однак нові методи страждають від недоекспозиції, і програмісти продовжують використовувати звичні та більш інтуїтивно зрозумілі методи getSubjectDN () & co.

Щоб змінити це, старі методи getSubjectDN () та getIssuerDN () повинні бути застарілими. Це забезпечить розробникам, які використовують ці методи, отримати попередження про час компіляції ....

ОЦІНКА

... Депресія була визнана недоцільною у цьому випадку. Натомість до JavaDoc додано застережливі коментарі .

Той факт, що читання програми Bug ID 5008142 вас збентежило з приводу цього "зневаженого" матеріалу, більше нагадує провину розробника, який вирішив це.

Вони повинні були знайти помилку 4959744 та вказати її на свою оцінку, а не розпливчасте твердження, "призначене для використання лише у серйозних випадках". Вони, ймовірно, навіть можуть бути закритими як дублікати, з обґрунтуванням на кшталт "Депресія була розглянута, оцінена та відхилена на користь зневаги за помилкою ID 4959744" .

По крайней мере, вони можуть посилати ідентифікатор помилки 4959744 (можливо, разом з 4638294 ) у полі " Пов'язані звіти" (званий Див. Також у старих bugs.sun.com iirc) свого трекера помилок. Те, що цього не було зроблено, змушує одного підозрюваного, що вони взагалі не шукали пов'язаних питань.

— гнат
джерело

1

@FrustratedWithFormsDesigner найважче було зрозуміти, як ввести "знецінено" на сторінці пошуку в Oracle, щоб результати фільтрувались на "bugs.sun.com". Решта було легко, я просто перевірив кілька результатів пошуку, які спливали. "Denigrate" - дуже гарне слово для пошуку :)

— gnat

1

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

— Якоб Шоен

@jschoen Я думаю, що це не стільки ваша провина; Я розширив відповідь на що

— комара

4

Після ще одного копання я зміг знайти публікацію в блозі під назвою " Позбавлення життя" в JDK . В основному йдеться про те, що речі, позначені застарілими , вважаються шкідливими для вживання, а також є деякі речі, які просто не рекомендуються.

Загальна політика для декількох випусків функцій полягає в тому, що основні компоненти JDK позначаються як устарені, лише якщо вони активно шкідливі. Якщо використання класу чи методу є просто необдуманим, цього, як правило, недостатньо, щоб заробити застарілу оцінку.

Він зазначив, що в даний час існує спосіб позначити предмет як відмовлений у використанні, але в кінцевому підсумку вони можуть додати спосіб зробити це.

У якийсь момент подібні поради можуть бути формалізовані з менш шкідливим, ніж устареним засобом "деградації" на основі комбінації тегів javadoc та анотацій, щоб дозволити програмні перевірки на використання цих менш шкідливих елементів API.

Хоча я не можу знайти нічого іншого конкретно щодо рішення використовувати термін Деніграція, це здається досить близьким. І виходячи з цього, здається, що розробник, який повинен вжити, такий же, як і устарений , не використовуйте метод.

— Джейкоб Шоен
джерело