我应该如何命名我的 Java 9 模块?
假设我有一个带有 和 的库。模块名称的建议名称是什么:或 ?有没有关于命名方案的官方指南?groupId = org.abc
artifactId = myLibrary
myLibrary
org.abc.myLibrary
假设我有一个带有 和 的库。模块名称的建议名称是什么:或 ?有没有关于命名方案的官方指南?groupId = org.abc
artifactId = myLibrary
myLibrary
org.abc.myLibrary
有一段时间,关于你的问题有两种不同的意见,但在模块系统的开发过程中,社区决定采用反向DNS方法。
此处的假设是模块名称应全局唯一。鉴于这一目标,实现目标的最实用方法遵循软件包命名策略,并反转维护者与之关联的域名。模块系统的状态是这样的:
模块名称(如包名称)不得冲突。命名模块的推荐方法是使用长期以来推荐用于命名包的反向域名模式。
此外,Mark Reinhold写道:
强烈建议所有模块按照反向互联网域名约定进行命名。模块的名称应与其主要导出的 API 包的名称相对应,该名称也应遵循该约定。如果模块没有这样的包,或者由于传统原因,它必须具有与其导出的包之一不对应的名称,则其名称至少应以与作者关联的Internet域的反向形式开头。
这很清楚,其他Java专家如Stephen Colebourne也分享了这一点。
有一段时间(2016年初),还有另一个建议在进行轮询。JDK团队表示,模块名称可能不必是唯一的,因为模块比定义它们的工件更抽象”。Mark Reinhold写道:
选择以项目或产品名称开头的模块名称。以反向域名开头的模块(和包)名称不太可能发生冲突,但它们不必要地冗长,它们以最不重要的信息(例如,,,或)开头,并且在诸如开源捐赠或公司收购(例如,))等外生更改(例如,)之后,它们读起来不好。
com
org
net
com.sun.*
在Java的早期,反向域名方法是明智的,当时我们拥有足够复杂的开发工具来帮助我们处理偶尔的冲突。我们现在有这样的工具,所以向前发展,以项目或产品名称开头的短模块和包名称的卓越可读性比那些以反向域名开头的冗长更可取。
此外,如果模块名称不包含域,则只要模块具有相同的名称(并且当然实现相同的公共 API),就可以将该模块与另一个实现交换。
在上面的邮件中,Reinhold记录了他的观点变化:
有些人可能更喜欢较短的,面向项目的名称,这些名称可以在有限的项目中使用,这些项目永远不会在单个组织之外看到曙光。但是,如果您创建的模块将来有很小的机会被开源,那么最安全的做法是在开始时为其选择反向DNS名称。
陪审团在场,每个公开他或她的意见的人都同意反向DNS,就像软件包一样。
我想我们从马克·莱因霍尔德(Mark Reinhold)那里得到了一个“官方”的答案:
强烈建议所有模块按照反向互联网域名约定进行命名。模块的名称应与其主要导出的 API 包的名称相对应,该名称也应遵循该约定。如果模块没有这样的包,或者由于传统原因,它必须具有与其导出的包之一不对应的名称,则其名称至少应以与作者关联的Internet域的反向形式开头。