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