假设我有一个包含groupId = org.abc和artifactId = myLibrary的库。模块名称的推荐名称是：myLibrary还是org.abc.myLibrary？是否有任何命名方案的官方指南？
答案 0 :(得分：30)
有一段时间，对于您的问题有两种不同的意见，但在模块系统的开发过程中，社区采用了反向DNS方法。
这里假设模块名称应该是全局唯一的。鉴于这一目标，最实用的方法是遵循包命名策略并反转维护者所关联的域名。 The State of the Module System says this：
模块名称（如包名称）不得冲突。命名模块的推荐方法是使用长期推荐用于命名包的反向域名模式。
此外，Mark Reinhold writes：
强烈建议根据反向Internet域名约定命名所有模块。模块的名称应该与其主要导出的API包的名称相对应，该API包也应遵循该约定。如果模块没有这样的包，或者由于遗留原因，它必须具有与其导出的包之一不对应的名称，那么其名称至少应该以作者的反向形式开头。相关联。
这非常清楚，并由其他Java专家like Stephen Colebourne分享。
有一段时间（2016年初）还有另一个建议进行轮次。 JDK团队表示模块名称可能不一定是唯一的“因为模块比定义它们的工件更抽象”。 Mark Reinhold writes：
选择以项目或产品名称开头的模块名称。以反向域名开头的模块（和包）名称不太可能发生冲突，但它们不必要地冗长，它们从最不重要的信息开始（例如，
com，org或{{ 1}}），在开源捐赠或公司收购等外生变化后（例如net），他们读得不好。在我们拥有足够复杂的开发工具来帮助我们处理偶尔的冲突之前，反向域名方法在Java的早期是明智的。我们现在有这样的工具，因此，以项目或产品名称开头的短模块和软件包名称的优越可读性优于那些以反向域名开头的繁琐冗长。
此外，拥有不包含域的模块名称将允许将该模块与另一个实现交换，只要它具有相同的名称（并且当然实现相同的公共API）。
在上面的邮件中，莱因霍尔德记录了他的意见变化：
有些人可能更喜欢较短的，面向项目的名称，而这些名称可以在有限的项目中使用，这些项目永远不会在单个组织之外看到光明。但是，如果您创建的模块在将来很少有机会开源，那么最安全的方法是在开始时为它选择反向DNS名称。
陪审团参与其中，所有公开发表意见的人都同意反向DNS，就像包裹一样。
答案 1 :(得分：3)
我认为我们得到了Mark Reinhold的“官方”answer：
强烈建议根据反向Internet域名约定命名所有模块。模块的名称应该与其主要导出的API包的名称相对应，该API包也应遵循该约定。如果模块没有这样的包，或者由于遗留原因，它必须具有与其导出的包之一不对应的名称，那么其名称至少应该以作者的反向形式开头。相关联。