假设我有一个带有groupId = org.abcand的库artifactId = myLibrary。模块名称的推荐名称是什么：myLibrary或org.abc.myLibrary？有命名方案的官方指南吗？
问问题
8743 次
2 回答
43
有一段时间对你的问题有两种不同的看法，但在模块系统的开发过程中，社区决定采用反向 DNS 方法。
唯一模块名称 - 反向 DNS
在这里，假设模块名称应该是全局唯一的。鉴于该目标，实现该目标的最实用方法遵循包命名策略并反转维护者关联的域名。模块系统的状态是这样说的：
模块名称，如包名称，不得冲突。命名模块的推荐方法是使用长期以来被推荐用于命名包的反向域名模式。
此外，马克·莱因霍尔德写道：
强烈建议根据反向 Internet 域名约定来命名所有模块。模块的名称应与其主要导出 API 包的名称相对应，这也应遵循该约定。如果一个模块没有这样的包，或者由于遗留原因，它必须有一个与其导出的包之一不对应的名称，那么它的名称至少应该以作者使用的 Internet 域的反转形式开头已关联的。
这一点很清楚，其他 Java 专家（如 Stephen Colebourne ）也分享了这一点。
模块大于工件
有一段时间（2016 年初），还有另一项建议在进行。JDK 团队表示，模块名称毕竟可能不必是唯一的，“因为模块比定义它们的工件更抽象”。马克·莱因霍尔德写道：
选择以项目或产品名称开头的模块名称。以反向域名开头的模块（和包）名称不太可能发生冲突，但它们不必要地冗长，它们以最不重要的信息（例如
com，，org或net）开头，并且在外生更改后它们无法很好地阅读例如开源捐赠或企业收购（例如com.sun.*）。反向域名方法在 Java 的早期是明智的，在我们拥有足够复杂的开发工具来帮助我们处理偶尔的冲突之前。我们现在有这样的工具，因此以项目或产品名称开头的短模块和包名称具有卓越的可读性，而不是那些以反向域名开头的繁琐冗长的名称。
此外，具有不包含域的模块名称将允许将该模块与另一个实现交换，只要它具有相同的名称（并且当然实现相同的公共 API）。
在上面列出的邮件中，莱因霍尔德记录了他的意见改变：
有些人可能更喜欢较短的、面向项目的名称，这些名称可以很好地用于有限的项目中，这些项目永远不会出现在单个组织之外。但是，如果您创建的模块将来开源的可能性很小，那么最安全的做法是在开始时为其选择一个反向 DNS 名称。
概括
陪审团在场，每个公开发表意见的人都同意反向 DNS，比如包。
于 2017-04-03T19:56:50.470 回答
5
我想我们从马克·莱因霍尔德那里得到了一个“官方”的回答：
强烈建议根据反向 Internet 域名约定来命名所有模块。模块的名称应与其主要导出 API 包的名称相对应，这也应遵循该约定。如果一个模块没有这样的包，或者由于遗留原因，它必须有一个与其导出的包之一不对应的名称，那么它的名称至少应该以作者使用的 Internet 域的反转形式开头已关联的。
于 2017-05-05T02:04:28.067 回答