有没有人知道com.company.project包结构的实际原因以及它为什么成为事实上的标准？
是否有人将所有内容存储在直接反映此包结构的文件夹结构中？ （这来自于Actionscript的观点，顺便说一下）
答案 0 :(得分：5)
防止名称冲突是这样的包结构的一个相当实际的原因。如果您使用的是您拥有的真实域名，并且其他所有人都使用相同角色的包名称，那么冲突的可能性很小。
ESP。在Java世界中，这是“预期的行为”。如果你想找到你正在使用的遗留库的文档，那么它也会有所帮助，无论人们在哪里都记不起来了; - ）
关于在这样的包结构中存储文件：在Java世界中，包是有效的文件夹（或.jar文件中的路径）所以：是的，很多人确实以这种方式存储文件。
这种结构的另一个实际优点是，您始终知道某个库是否是内部开发的。
答案 1 :(得分：2)
我经常跳过com。因为即使是小型组织也有多个TLD，但在名称空间中拥有所有者名称绝对有用，因此当您开始入门第三方库时，您没有名称空间冲突。
想想那里会有多少Utility或Logging命名空间，至少我们有Foo.Logging和Bar.Logging，dev可以将一个命名空间别名：）
答案 2 :(得分：1)
如果您从您拥有的域名开始，向后表示，那么只有在此之后，您才能与遵循相同结构的任何其他人发生冲突，因为没有其他人拥有该域名。
它仅在某些平台上使用。
答案 3 :(得分：1)
有几个原因：
对于第二点，请考虑将日期记录存储在分层文件结构中的示例。将YYYY/MM/DD分层次排列为比DD/MM/YYYY更为明智：在根级别，您会看到按年份组织记录的文件夹，然后是按月组织记录，最后是按天组织。以另一种方式（在根级别按天或数月）这样做可能会相当尴尬。
对于域名，它通常为subsub.sub.domain.suffix，即从小到大。这就是为什么在将其转换为分层包名称时，您会得到suffix.domain.sub.subsub。
首先，这里是 Java语言规范第3版的摘录，可以为这个包命名约定提供一些启示：
7.7 Unique Package Names
开发人员应采取措施，通过为广泛分发的软件包选择唯一的软件包名称来避免两个已发布的软件包具有相同名称的可能性。这样可以轻松自动地安装和编目软件包。本节指定用于生成此类唯一包名称的建议约定。鼓励Java平台的实现提供自动支持，以便将一组包从本地和临时包名转换为此处描述的唯一名称格式。
如果未使用唯一的包名称，那么包名称冲突可能远远超出任何冲突包的创建点。这可能会造成用户或程序员难以或不可能解决的情况。在包有约束交互的情况下，类
ClassLoader可用于隔离具有相同名称的包，但不能以对初始程序透明的方式隔离。您首先拥有（或属于具有）互联网域名的组织（例如
sun.com），从而形成唯一的包名称。然后，您可以逐个组件地反转此名称，以获取com.sun，在此示例中，使用此名称作为包名称的前缀，使用组织内部开发的约定来进一步管理包名称。包名称并不意味着包裹存储在互联网中的位置;例如，名为
edu.cmu.cs.bovik.cheese的包不一定是从Internet地址cmu.edu或cs.cmu.edu或bovik.cs.cmu.edu获得的。 生成唯一包名称的建议约定仅仅是在现有的，广为人知的唯一名称注册表之上搭载包命名约定的方法，而不是必须为包名称创建单独的注册表。