为什么不推荐使用isJavaLetterOrDigit？

为什么不推荐使用isJavaLetterOrDigit的java.lang.Character？为什么不推荐使用isJavaLetterOrDigit？

该文档说，应该使用方法isJavaIdentifierPart来代替，但不指明原因。这两种方法的文档是相同的。谷歌搜索这个问题没有任何解释。

实际上，一个源代码搜索显示，现在，只需调用另一个，所以行为没有区别。它是否被弃用，因为它有一个更令人困惑的名字？看起来像一个相当奇怪的决定。

@Deprecated 
public static boolean isJavaLetterOrDigit(char ch) { 
    return isJavaIdentifierPart(ch); 
}

来源

2013-04-28 Antimony

旧的（不建议使用的）名称没有正确反映实际执行的内容;例如它接受既不是字母也不是数字的字符。我想这会导致一些“错误”报告和困惑的开发人员的支持请求。国际海事组织，这是他们采取（重大）创建新方法并贬低旧方法的最可能的原因。（@HuiZheng提出的其他原因是在知识层面上的有效点，但不足以证明不推荐使用方法。Java人不会仅仅依靠良好的API设计原则来绕过改变的API。为开发人员提供工作，而Oracle不想疏远支付这些程序员工资的公司，因为Java作为一个稳定平台的声誉，Java已经在企业界赢得了如此多的关注！）

无论如何，废除这种方法似乎对我来说）就像一个明智的，合理的API设计决策。无论哪种方式，我们的意见都是没有意义的。

来源

2013-04-28 02:49:31

原因1：

一个好的API名称应该是足够抽象的（但不是过于抽象）。 isJavaLetterOrDigit太实现导向。如果您确实想要这样，请改用isLetterOrDigit。

原因2：

一个好的API名称应确切指定其目的，应正确实施。 isJavaLetterOrDigit是误称，因为它实际上允许使用非字母或数字字符，如“_”或“$”。

原因3：

一个好的API名称应该是谐波与他人。 isJavaIdentifierPart与其他API一致，如isJavaIdentifierStart,isUnicodeIdentifierPart,isIdentifierIgnorable。

最后，仅仅因为这两个API之间的行为没有差异，并不意味着它们是相同的。误导性的API名称会破坏您的代码。此外，总是尽快转储弃用的API，因为它们最终（或很有可能）会被库提供商倾销。

来源

2013-04-28 03:08:22

由于二进制兼容性的原因，它们不能被库提供者转储。 – EJP 2013-04-28 03:31:33

@EJP我知道兼容性原因，不赞成使用的API通常会保留一段时间。但从长远来看，图书馆提供商可能会选择打破这种兼容性。无论如何，我们不想冒这个风险。 – 2013-04-28 03:41:03

@惠正 - 根据以往的历史，该方法不会被删除。甲骨文或其（付费）客户的利益并不在于这么做。文件说这*可能会发生......但我预测它*不会*。（或者至少，除非Oracle能够提供可靠的工具来自动升级源代码和字节码级别的旧代码）。 – 2013-04-28 03:51:06

为什么不推荐使用isJavaLetterOrDigit？

回答

相关问题