Java 更改包名称大小写约定的原因答案

【问题标题】：Java reason for changing of package name case conventionJava 更改包名称大小写约定的原因
【发布时间】：2017-01-06 23:54:18
【问题描述】：

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

所以我在阅读Thinking in Java -Bruce Eckel，这段话是关于小写命名约定的：

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

我在“发现这会导致问题”时遇到问题。什么问题？不可能是域名冲突，因为域名都是大写的，对吧？

我在谷歌上搜索过这个，但我得到的是：Why should java package name be lowercase?：

包名全部小写，避免与类名或接口名冲突。

我也搜索过java package lowercase convention changed all-caps domain name，但无济于事。

那么有人知道他们为什么中途更改了命名约定吗？

【问题讨论】：

我从未在任何 Java 库中看到这些单词大写。
@markspace 好吧，作者显然看到了 Java 的发展和成长。 Java 1 和 1.1 一定很古老。
区分大小写的文件系统有问题吗？
@assylias 但是如果将大小写更改为全小写，问题仍然存在，对吧？
我从 1.1 开始使用 Java，从未见过大写的包名。

标签： java naming-conventions

【解决方案1】：

只是一个疯狂的猜测，不是基于任何可靠的来源：包名称与文件系统目录结构相关联。包含NET 的包名称可能会导致问题，例如来自区分大小写的文件系统的源代码树被复制到/在不区分大小写的文件系统上使用，并且无论出于何种原因，目录名称都从“NET”更改为等效的“net”。

在相反的方向上也是如此：从包名称解析文件系统路径，我可以设想这可能会导致一些歧义或至少让用户感到意外的情况。

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

另一个潜在问题是它与类命名约定中允许的内容相冲突。类通常是第一个字母大写的，但它并不少见，例如首字母缩写词都是大写，例如一个名为API 或COM 的类。这允许包和类命名约定之间存在一些重叠。但我的感觉是文件系统问题更可能是问题。

【讨论】：

在某些版本的某些 Windows 文件系统中，以全大写形式输入的名称默认以全小写形式显示。这可能是为了对来自不区分大小写的系统的文件友好——这些文件可能全大写，全小写看起来更好。虽然文件名在幕后仍然是大写的，但这可能会引起混淆。当然，这一切都只是猜测。
我找不到 James Gosling 的电子邮件（笑），但我给 Bruce Eckel 发了一封信。也许他会回复。
他回复了！但是，唉，看起来他的猜测和我们的一样好：“很抱歉，那是很久以前的事了，尤其是在早期的 Java 时代，有很多设计小问题，所以我不记得了。那绝对应该一直是书中的一个脚注。但是，一个 SO 回复者提到的 Windows 大写/小写处理听起来似乎是合理的。” 至少我觉得我的猜测有些验证，哈哈。
我想我现在明白这个问题了。谢谢。不过没想到给作者发邮件。但至少现在这个问题在互联网上已经很清楚了，所以其他人可以看到他们是否来自这本书。

【解决方案2】：

我认为书中的引用指的是如下错误：RS01799: IMPLEMENTATION CLASS IS NOT FOUND WHEN A JAVA PACKAGE NAME START S WITH AN UPPER CASE CHARACTER。

我认为作者写的不是程序员的困惑，而是内部 JVM 实现。我已经使用 JDK 1.8 进行了测试，但无法重现该问题。请注意错误报告描述中“可能找不到”的使用。

【讨论】：

这是一个很好的猜测，也许是这样的。尽管这是在 2014 年提交的（Java 1.2 于 1998 年发布）并且可能是程序员的困惑，例如某些反射逻辑或某事中的 WS 决策服务器实现错误。但是，是的，可能是这样的，所以+1。
我注意到了日期，但引用的书说它是在 Java 1.2 中发现的，所以标准被改变了。没有关于何时/是否修复的消息。但是，当然这也可能是程序员的困惑。使用数据库而不是文件系统的 JVM 实现也可能导致问题。当前文档中的短语“避免与类或接口的名称冲突”表明在某些情况下可能仍然存在冲突。我希望布鲁斯·埃克尔能回复你的来信。