JavaDoc中不推荐使用vs.

11

在JavaDoc中X509Certificate getSubjectDN()指出：

Denigrated，由getSubjectX500Principal（）代替。

我习惯在for方法中看到已弃用，该方法不再使用，但不可贬低。我发现了一个有关此特殊情况的错误报告，该错误报告已通过注释关闭：

这不是错误。“不推荐使用”仅在严重情况下使用。

当我们使用不推荐使用的方法时，建议采取的一般措施是停止使用该方法。

那么，将方法标记为“已贬义”时，建议采取的措施是什么？

java terminology javadocs

— 雅各布·肖恩
source

2

哇。我已经阅读了答案，虽然我确定它们在技术上是正确的，但“贬义”是一个可怕的词。他们应该只使用“ Discouraged”。无需吐出代码；一个警告就足够了。

— 埃里克·金

@Eric King我也有同样的感觉。我一直在想，如果不鼓励，则不建议使用。

— Jacob Schoen

9

Merriam-Webster对贬义词的定义表明：

1：攻击声誉：诽谤 <den毁对手>
2：否认重要性或有效性：贬低 <贬低他们的成就>

基于什么是写在另一个相关的错误，诽谤/贬低看来符合意图在使用的Javadoc措辞- 错误ID：4959744诋毁X509Certificate.getSubjectDN（）＆CO：

该方法getSubjectDN（）和getIssuerDN（）在x509证书和getIssuerDN（）在X509CRL是有问题的。他们返回一个未指定的实现java.security.Principal接口的类，该接口的规范非常宽松。

由于getSubjectDN（）和getIssuerDN（）方法中没有附加的规范，因此实现可以返回任意的，实现特定的类。实际经验表明，这种情况导致代码不可移植或不可靠。出于兼容性原因，这些方法的规范不能更改，必须将其视为不可挽救的。

JDK 1.4中添加了替换方法getSubjectX500Principal（）＆co，该方法返回定义良好的X500Principal类的实例。这些方法的实现已设计为避免此类所有问题。但是，新方法的曝光不足，程序员继续使用熟悉且更直观的getSubjectDN（）＆co方法。

要更改此设置，建议不要使用旧的getSubjectDN（）和getIssuerDN（）方法。这将确保使用此方法的开发人员收到编译时警告...。

评价

...在这种情况下，过时被认为是不合适的。相反，警告注释已添加到JavaDoc中。

读取Bug ID 5008142会使您对这种“被贬低的”东西感到困惑的事实看起来更像是处理它的开发人员的错。

他们应该找到错误4959744并在评估中引用它，而不是模糊的声明“仅在严重情况下才使用”。他们甚至可能以重复的形式关闭，理由是“已考虑，评估并拒绝了弃用，以便根据Bug ID 4959744进行贬义”。

在非常非常至少，他们可以参考错误ID 4959744（也许连同4638294）在相关报表字段（称为另请参见旧bugs.sun.com IIRC）的bug跟踪系统的。尚未做到这一点使人们怀疑他们根本没有寻找相关问题。

— gna
source

1

@FrustratedWithFormsDesigner最难的部分是弄清楚如何在oracle搜索页面上输入“已贬义”，以便将结果过滤到“ bugs.sun.com”。其余的很简单，我只是检查了少数弹出的搜索结果。“诋毁”是搜索一个相当不错的话:)

— 蚊蚋

1

看到我曾经用Google找到第一个，但是没有给我其他的。我可能应该看起来更努力。谢谢

— 雅各布·斯科恩

@jschoen我认为这不是你的错。我详述了这一个答案

— 蚊蚋

4

经过更多的挖掘之后，我能够在JDK中找到名为Deprecation的博客文章。它基本上指出标记为“ 已弃用”的事物被认为有害使用，并且有些事物被劝阻。

几个功能版本的一般政策是，核心JDK组件只有在对它们有害时才被标记为已弃用。如果使用类或方法不明智，通常这不足以赢得不推荐使用的分数。

他提到目前不存在将某项标记为不鼓励使用的方法，但他们最终可能会添加一种执行此操作的方法。

在某些时候，这种建议可能会以一种比Java标记和批注相结合的危害程度不及弃用的“贬义”工具形式化，以允许对这些危害程度较小的API元素的使用进行程序检查。

尽管我找不到关于决定使用“ 贬义 ”一词的其他决定，但这似乎非常接近。基于此，开发人员应该采取的行动与Deprecated相同，不要使用该方法。

— 雅各布·肖恩
source