命名空间_uts命名空间[通俗易懂]

免责声明：这是我的个人观点，并不代表雇主的观点。

到目前为止，由于从Oracle迁移到Eclipse Foundation，每个人都知道我们需要将所有javax软件包名称重命名为其他名称。

（供参考，请参阅附录A）

目前基本上是讨论，我们应该一次全部重命名，还是在更新API时分阶段重命名（我相信我们现在应该全部重做并克服它），目前大多数人都认为我们会将所有javax重命名为jakarta 。

正在进行的另一讨论是MicroProfile和Jakarata EE之间的关系。 我认为这两个小组应该保持独立，但要共同努力。 但是，如何工作仍在讨论中。

将品牌与规范脱钩。

目前，MicroProfile下的所有规范都使用名称空间（或包名） org.eclipse.microprofile ，并且如前所述，Jakarta EE的建议是jakarta 。 两者的groupId和artifactId类似，都包含“品牌”名称（雅加达或MicroProfile）。

尽管这很有意义，并且大多数人都认为品牌应该在这两种形式中都可见，但这将规范与品牌或分组结合在一起。

我的建议是从名称空间和Maven工件中删除品牌。 这意味着我们失去了一些品牌元素，但获得了灵活性。 通过从规范中删除分组，使该规范与某个总括项目相关的唯一事情是处理这些规范的工作组。 （从事此规范工作的人员）

例如，我们没有重命名为org.eclipse.enterprise ，而是从javax重命名为jakarta 。 （只是一个例子）

因为我们可以在MicroProfile中进行重大更改，所以我们还从MicroProfile API中删除了品牌，并将API重命名为org.eclipse.enterprise 。

MicroProfile和Jakarta EE关系。

目前，MicroProfile依赖于Jakarta EE（但并非相反）。 我建议您保持这种关系，所以只有这种关系可以解决。

MicroProfile是进行创新和试验的好地方，但不是（必需）向后兼容的地方。 这使MicroProfile在创建新规范时可以快速移动。

但是，在某些时候，新的API确实已经成熟并且稳定，并且没有添加任何新的主要功能，并且该API变得相当稳定。 在这一点上，也许值得一看，该工作是否应该移至Jakarta工作组，并从那时起就支持向后兼容。 MicroProfile伞仍然会依赖于它，但是以与依赖它从Jakarta EE提取的其他API相同的方式。

由于上述建议的命名方式，因此代码不会更改，并且用户可以继续正常运行，唯一的不同是Jakarta EE具有新的API，并且该规范现在由另一个工作组和另一个Eclipse进程维护。

配置示例。

如果我们以config为例，则该API在MicroProfile下已经成熟，并且（可能）将工作组移至Jakarta。 在Jakarta或JSR下拥有另一个标准，可能不是一个好主意。 如果只有一个标准，则只有一个标准。 在我看来， JSR382应该退役，转而使用迁移到雅加达的MicroProfile Config API。

未来分组。

一旦有了在品牌或分组之间移动API而不影响代码和客户的机制，我们就可以考虑其他分组，并且可能是从雅加达“淘汰”某些API的一种方式。

例如，如果我们在eclipse下创建一个新的分组，我们将其称为ClassicProfile，就像MicroProfile一样，我们可以让ClassicProfile依赖于Jakarta，而不是相反。 然后，我们可以将不再需要在雅加达使用的旧API移到此配置文件中。 这意味着使用这些客户端的客户仍然可以在不更改代码的情况下获得它们，但这意味着我们可以节食Jakarta EE并使其更薄。

最后的想法

与大多数架构决策一样，需要权衡取舍。 在这种情况下，品牌与可移植性。 但是我认为这样做是值得的。 现在这样做也很重要，我们有机会重命名当前的javax名称空间，所以现在还是永远不会。

附录A

• 原始公告和此Twitter线程
• 来自Red Hat的Mark Little
• Ian Robinson，IBM的Kevin Sutter
• 来自Payara的Steve Millidge
• 来自Tomitribe的David Blevins
• 伊瓦尔·格里姆斯塔德
• 马克·斯特鲁伯特

翻译自: https://www.javacodegeeks.com/2019/09/proposed-namespace-jakarta-ee.html