Java包命名规范改变的原因是什么？

Question

在你说这是重复问题之前，我已经看到了其他的问题，但我仍然想发布这个问题。

所以我在读Bruce Eckel的《Java编程思想》时，看到了关于小写命名规范的这段话：

在Java 1.0和Java 1.1中，域扩展名com、edu、org、net等都是按照惯例大写的，因此库会显示为NET.mindview.utility.foibles。然而，在Java 2的开发过程中，发现这会引起问题，因此现在整个包名都是小写的。

我的问题出在“发现这会引起问题”上。是什么问题？这不可能是名称冲突，因为域名都是大写的，对吧？

---

我在Google上搜索了这个问题，但是得到的都是：为什么Java包名应该小写？:

包名使用全小写是为了避免与类或接口的名称冲突。

我还搜索了 java package lowercase convention changed all-caps domain name 但没有结果。

---

有人知道为什么他们在中途改变了命名规则吗？

- Daniel Cheung

---

我从未在任何Java库中看到这些词被大写。 - markspace

@markspace 嗯，作者显然看到了Java的发展和成长。Java 1和1.1肯定是古老的版本。 - Daniel Cheung

大小写（不）敏感的文件系统有问题吗？ - assylias

我从1.1版本开始学习Java，从未见过大写的包名。 - chrylis -cautiouslyoptimistic-

《Java编程思想》是一本不错的书，但现在已经有些过时了。我同意@markspace的观点——我从未见过使用域名扩展名大写的包。 - duffymo

Answer 1

只是一个猜测，没有可靠的来源支持：包名与文件系统目录结构相关联。如果包名中有NET，在区分大小写的文件系统上复制源树并更改目录名称从“NET”到等效的“net”，可能会出现问题。

同样，在相反的方向上，解决来自包名称的文件系统路径，我可以想象这可能会导致一些模糊不清的情况或至少会让用户感到惊讶。

我可以看到这在某些情况下会引起混乱。

另一个潜在的问题是它与类命名约定的可允许性相冲突。类通常以首字母大写，但缩写词往往全部大写，例如命名为API或COM的类。这导致了包和类命名约定之间的一些重叠。但我的感觉是文件系统问题更可能出现问题。

- Jason C

---

在某些 Windows 文件系统的某些版本中，以全大写输入的名称将默认显示为全小写。这可能是为了对不区分大小写的系统中的文件更友好 - 这些文件可能以全大写形式出现，并且以全小写形式看起来更好。虽然文件名在幕后仍然是大写的，但这可能会导致混淆。当然，这只是猜测。 - Ole V.V.

我找不到James Gosling的电子邮件（哈哈），但我给Bruce Eckel写了一封信。也许他会回复。 - Jason C

他回复了！但不幸的是，看起来他的猜测和我们一样好：“非常抱歉，那是很久以前的事情，特别是在早期的Java时代，有很多设计问题，所以我不记得了。那应该在书中作为脚注。然而，一个SO回答者提到的Windows大写/小写处理听起来是可信的。”好吧，至少我感觉我的猜测有些被证实了，哈哈。 - Jason C

我现在认为我理解了那个问题。谢谢。虽然没有想到给作者发电子邮件，但至少现在问题已经在互联网上明确了，所以其他人如果来自这本书，就可以看到这个问题。 - Daniel Cheung

Answer 2

我认为书中的引用指的是以下错误：RS01799: 当Java包名以大写字符开头时，找不到实现类。

我认为作者讨论的不是程序员的困惑，而是内部JVM实现。我使用JDK 1.8进行了测试，但无法复现该问题。请注意缺陷报告描述中使用了“可能找不到”的措辞。

- acm

---

那是个好猜测，也许就是那样。虽然那是在2014年提交的（Java 1.2发布于1998年），可能是程序员混淆了一些东西，比如WS决策服务器实现中的一些反射逻辑错误之类的。但是没错，可能是这样的情况，所以+1。 - Jason C

我注意到日期，但引用的书中说它是在Java 1.2中发现的，因此标准已经改变。没有提到何时/是否修复。但是，这也可能是程序员混淆。使用数据库而不是文件系统的JVM实现也可能会导致问题。当前文档中的短语“避免与类或接口的名称冲突”表明在某些情况下仍可能存在冲突。我希望Bruce Eckel回复你的信件。 - acm