在模块系统开发过程中,对于您的问题存在两种不同的观点,但社区最终采用了反向DNS方法。
这里的假设是模块名称应该是全局唯一的。考虑到这个目标,实现这个目标的最实用的方法是遵循包命名策略,并反转与维护者相关联的域名。 模块系统状态 表明:
模块名称(如包名称)必须不冲突。命名模块的推荐方式是使用反向域名模式,这一做法长期以来一直被推荐用于包的命名。
此外,Mark Reinhold 写道:
强烈建议所有模块都按照反向互联网域名约定进行命名。模块的名称应与其主要导出的 API 包的名称相对应,该包也应遵循该约定。如果模块没有这样的包,或者由于遗留原因必须具有不对应于其导出包之一的名称,则其名称至少应以作者关联的互联网域名的反转形式开头。
这很清楚,并且得到其他Java专家 如Stephen Colebourne 的认可。
有一段时间(2016年初),存在另一个建议。JDK团队表示,模块名称实际上可能不需要是唯一的“因为模块比定义它们的构件更抽象”。Mark Reinhold 写道:
选择以项目或产品名称开头的模块名称。 以反转域名开头的模块(和包)名称不太可能产生冲突,但它们过于冗长,它们以最不重要的信息开头(例如,
com
,org
或net
),并且在外部更改(例如开源捐赠或公司收购)后读起来不太好(例如,com.sun.*
)。在Java早期,采用反向域名方法是明智的,因为我们没有足够复杂的开发工具来帮助我们处理偶尔的冲突。现在我们已经拥有这样的工具,所以前进的道路上,以项目或产品名称开头的短模块和包名称的可读性优于以反向域名开头的冗长名称。
另外,不包含域名的模块名称允许将该模块与另一个实现进行交换,只要它具有相同的名称(当然还要实现相同的公共API)。
在上面引用的邮件中,Reinhold记录了他的观点变化:
一些人可能喜欢更短的、以项目为导向的名称,对于永远不会在单个组织外看到光的有限项目来说,这些名称可以使用。 但是,如果您创建的模块将来即使有一点点可能成为开源,那么最安全的方法就是从开始就选择反向DNS名称。
总结
陪审团已经做出了裁决,并且每个公开发表意见的人都同意像包一样采用反向DNS。
我认为我们从Mark Reinhold那里得到了一个“官方”的答案:
强烈建议按照反向互联网域名约定命名所有模块。模块的名称应对应于其主要导出API包的名称,该名称也应遵循该约定。如果模块没有这样的包,或者由于遗留原因必须具有不对应于其导出包之一的名称,则其名称至少应以作者关联的互联网域的反向形式开头。