jakarta

Eclipse Foundation 宣布Jakarta EE无法继续使用javax软件包名称。 显然，这是因为Java EE以此名称为基础，但不允许对该名称或以该名称开头的类或包进行进一步的修改。

尽管这当然是个坏消息，但对我来说，当宣布Jakarta EE不能将javax名称用于新的规范和子包时，这个坏消息已经开始。 那已经意味着继续发展一个随着时间的推移变得越来越不一致的平台。

考虑到我们所处的情况，我认为jakarta并迁移到建议的jakarta名称是有意义的。

这无疑对整个Java生态系统产生了巨大影响，这一切都基于任何Enterprise API，而不仅仅是标准本身。 如何合理解决？

我认为最重要的目标是最大程度地降低对用户(即开发人员)的影响。 除了项目中的代码用法之外，我还看到必须进行两个主要更改。

任何知道并处理EE API的运行时，例如应用程序服务器，都必须适应并切换到新名称。 他们必须实现某些功能才能与javax和jakarta ，这很可能同时发生，这仅仅是因为必须这样做。 那里有太多的代码无法迁移到基于javax或jakarta方式。 在现实世界中，有遗留项目，大量的库和依赖项，没有源的二进制文件等等。 我们需要一种方法来告诉运行时至少在临时运行时或在特定的兼容性配置文件中同时运行。 已经有一些建议如何做到这一点，包括字节码操作和其他黑魔法：-)我已经与IBM工程师交谈过，这也是Liberty的发展方向。 对我来说，让开发人员的生活更轻松是最重要的。

第二个重大影响将是针对围绕Enterprise Java构建的框架，库和工具，这些框架，库和工具会使用Java EE中包含的javax导入某些内容。 至少一旦引入了一些新功能，就必须进行切换。 如果他们想确保即使没有“兼容性运行时”，他们的项目仍可以在Jakarta EE下运行，他们也必须进行切换。 我认为一个明确的方法是在Java EE和javax以及Jakarta EE和jakarta下提供当前的Java EE API。 平台( javaee-api )和单独的规范(例如JAX-RS)都将需要此javaee-api 。 然后，这些项目可以通过其解析的依赖项来轻松控制，以使用并可以相应地交换其导入。 例如，如果Jakarta EE做到了干净利落，仅在下一个发行版(例如9或8.1切换到jakarta命名空间，而其他方面与Java EE 8保持相似，这将使项目切换更加容易。

TL; DR

我认为，雅加达EE生态系统应：

  • 最小化对用户(即开发人员)的影响
  • 使运行时至少暂时或在兼容性配置文件中同时支持javax和jakarta
  • 无需切换任何其他功能，即可轻松切换Jakarta EE平台和各个标准中的软件包名称

发现帖子有用吗？ 订阅我的时事通讯，获取有关IT和Java的更多免费内容，技巧和窍门：

成功！ 现在检查您的电子邮件以确认您的订阅。