我刚刚提出Java SE＆amp; S的学习曲线对包名称的通常Java约定没有问题，例如com.example.library_name_here.package_name_here
除。
我注意到在一些相当知名的软件包中没有遵守这个规则。
jline.* com.jacob.*（没有jacob.com）com.sun.jna.*（网站上的免责声明说明：Sun不赞助此项目，即使包名称（com.sun.jna）可能另有暗示。）所以我想知道，是否存在通常的反向域名约定失效的情况，并且有很好的方法可以绕过它？我能想到的唯一案例是围绕域名所有权问题（例如，您更改了项目托管/域名，或者已经有一个众所周知的软件包对您的域名具有“擅自占用权”，或者您对域的所有权运行out＆amp; others别人把它搞砸了。）
编辑：如果我使用我公司的域名，我们被收购或分拆，我们应该如何处理包名？保持相同或重命名？ （我认为从引用包的编译类失败的角度来看重命名是不好的）
答案 0 :(得分：12)
这是一个命名惯例。没有真正的要求，甚至没有期望包名映射到域名。
答案 1 :(得分：5)
一般的想法是两个组织不会拥有相同的域，因此使用域名作为包的一部分可确保没有命名空间冲突。但这只是一个建议。
有一个很好的理由让某人在sun命名空间中拥有包。如果他们提供公共API的实现，则通常需要在API的命名空间中实现这些类。
答案 2 :(得分：3)
如果您正在逐步掌握Java学习曲线，我会更加担心您的包装结构清晰，以便您可以轻松找到所需的课程。
答案 3 :(得分：2)
唯一重要的事情（恕我直言）是包名称的各个部分按重要性“排序”，即你最终没有使用gui.myprog，util.myprog，main.myprog，而是使用myprog。 gui，myprog.util和myprog.main。包名称是否真的以顶级域名开头，后跟域名，我无需担心。
答案 4 :(得分：2)
包用于避免各种实体构建的组件之间的模糊和冲突。只要您遵循惯例，并且没有人非法使用您的包命名空间饼图，您就不必担心其他人使用过的内容。
答案 5 :(得分：1)
您不能将语言关键字用作包名称的一部分，这是另一种无法应用域名约定的情况 - LONG Building Technologies
的运气不好然而，惯例只是一个惯例，而且它存在的唯一原因是它最大限度地减少了不同项目意外选择相同包名的可能性。如果你不能遵循它，那不是一个大问题。