苏州公司做变更网站,网站设计前景,视频网站 flash h5,商品定制平台网站免责声明#xff1a;这是我的个人观点#xff0c;并不代表雇主的观点。 到目前为止#xff0c;由于从Oracle迁移到Eclipse Foundation#xff0c;每个人都知道我们需要将所有javax软件包名称重命名为其他名称。 #xff08;供参考#xff0c;请参阅附录A#xff09; … 免责声明这是我的个人观点并不代表雇主的观点。 到目前为止由于从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 RobinsonIBM的Kevin Sutter 来自Payara的Steve Millidge 来自Tomitribe的David Blevins 伊瓦尔·格里姆斯塔德 马克·斯特鲁伯特 翻译自: https://www.javacodegeeks.com/2019/09/proposed-namespace-jakarta-ee.html
