将ActiveMQ转换为Jakarta（第二部分）

许多Java开发人员因为新的Jakarta框架的影响而面临升级他们的应用程序。在第一部分中，我写了关于Jakarta的简介（DZone文章，以及原始帖子），提供了一个入门指南。

简单明了，不是吗？只需将所有的 import javax.foo 改为 import jakarta.foo 这样就可以了！不是吗？哦，天哪。

最近，我通过一个大型且历史悠久的开源项目，这个项目是HYTE平台核心的一部分，经历了这个过程，我来分享一下。我相信我的经验代表了许多企业Java开发人员正在经历的事情，我希望分享经验和在这个过程中得到的见解。让我们深入了解。

背景

ActiveMQ是世界上使用最广泛的消息代理。ActiveMQ是HYTE MQ的引擎，它是HYTE消息平台作为服务的引擎。ActiveMQ的代码基础成熟，包括30多个Maven模块，涵盖了许多最常用的Jakarta EE API。

这不是“Hello World”

对ActiveMQ来说，直接转向Jakarta不是一个现实的选择，因为它被广泛应用于消息传递和集成基础设施。ActiveMQ的一个关键特性是它可以很容易地嵌入单元测试中，这导致许多其他开源项目将其用作测试依赖项，以验证这些项目的JMS集成能力。

尽管Jakarta命名空间的更改本身非常微小，但对于一个规模较大的现有基于Java的代码库来说，主要工作将来自于支付任何未完成的技术债务，然后升级ActiveMQ以采用规范中的变化。

ActiveMQ的技术债务

升级支持的JMS版本

在进行命名空间转换之前，ActiveMQ需要现代化支持的JMS API版本，从JMS 1.1版本升级到JMS 2.0版本的JMS API规范。这次修订变更是一个相当大的跃升，因为它添加了一组新的API类，允许简化的编码接口和运行时异常而不是受检异常。

幸运的是，JMS 2.0 API规范升级没有破坏或移除JMS 1.1规范中的任何内容。这使得企业代码库可以很容易地按照升级方式进行。我将在另一篇文章中更详细地介绍这个过程。

Servlet规范和Spring v5到Spring v6都有破坏性更改。这意味着需要重构使用这些API和框架的ActiveMQ代码。

升级框架

大型基于Java的代码库通常会依赖于许多其他框架，特别是在单元测试和集成测试中。这在对成熟的代码库进行转换时提出了一个很大的挑战，因为并非所有框架目前都在积极维护或具有Jakarta支持的发布版本。例如，一些流行的工具（如Jolokia）没有基于Jakarta的发布版。其他框架处于鸡和蛋问题中（如Apache Camel），它们有依赖项（通常用于单元测试或集成测试），这些依赖项需要先有基于Jakarta的发布版本，然后它们才能提供基于Jakarta的发布版本。

升级Jetty版本

支持Jakarta的框架通过重大版本升级来进行发布。例如，ActiveMQ正在使用Jetty 9。为了获得支持Jakarta命名空间的Jetty版本，ActiveMQ需要升级到Jetty v11。然而，在v9.x、v10.x和v11.x之间，Jetty并不仅仅改变了Jakarta命名空间。在这个过程中，Jetty内部API发生了变化。这意味着ActiveMQ需要同时采纳这些API变更和Jakarta命名空间变化。如果我有机会重新做一次，我会选择在ActiveMQ 5.18.x中采用Jetty v10，然后首先调整这些API变更。这将减少ActiveMQ 5.18.x和6.0.x版本之间的范围和差异。此外，这将使任何后移补丁的源代码管理变得更加简单。

Jetty做对了一切

ActiveMQ 5.x需要进行2次重大版本跳跃才能达到Jakarta。这是一个比预期更大的努力的例子，企业用户将看到Jakarta迁移范围不断扩大，花费的时间比预期长。在ActiveMQ的情况下，使用Jetty的组件对于大多数用户来说不是关键路径。基于Jetty的组件支持客户端的HTTP和Web套接字传输。这些使用频率较低的组件需要的补丁较少。如果需要Jetty的ActiveMQ组件在关键路径上，或者预期未来需要大量进行后移操作，那么更好的做法是在启动Jakarta转换之前让ActiveMQ 5.x版本升级到Jetty 10。

意外情况

在ActiveMQ的Jakarta迁移工作进行中，Jetty发布了一个支持javax.*和jakarta.*命名空间的v12。如果在迁移过程开始时就有Jetty 12.x，决定将非常容易，ActiveMQ 5.x和ActiveMQ 6.x都将升级到Jetty 12。这种情况可能会在未来发生。

采取的路径

步骤 1

在非Jakarta发布中实现JMS 2.0支持。ActiveMQ 5.18.x发布包括大部分JMS 2.0功能（请参阅：Apache ActiveMQ JMS / Jakarta状态页面）。

步骤 2

添加过渡客户端jar，以便开发人员可以开始将基于Jakarta的客户端应用程序与非Jakarta的ActiveMQ服务器端集成。activemq-client-jakarta模块被创建为标准activemq-client（使用javax.jms命名空间）的简单重新打包，但使用jakarta.jms命名空间。这是一个重要的进展！现在，任何使用ActiveMQ作为JMS客户端的应用程序，需要Jakarta基础客户端功能的应用程序不再受阻，而是可以立即开始使用，而不必等待开源项目完全完成基于Jakarta的过渡。Spring Boot的v3.x ActiveMQ启动器已更新为使用activemq-client-jakarta，以向用户提供过渡支持，直到完成基于Jakarta的完整ActiveMQ版本。

步骤 3

分析ActiveMQ代理端对Jakarta的支持

步骤 4

重构ActiveMQ以进行必要的更改。降低技术债务。Spring和Jetty的更改。移除并替换未维护的依赖项。

步骤 5

现代化代码库。更新Java JDK 17的语言特性，调整Maven依赖项等。

步骤 6

发布基于Jakarta的ActiveMQ 6.0.0

迁移方法范围扩大

随着用户开始采用随Active 5.18.x发布的activemq-client-jakarta库，许多用户需要的不仅仅是简单的客户端jar来支持他们的应用程序中的Jakarta。遵循HYTE最佳实践的应用程序还需要一个支持Jakarta的activemq-jms-pool项目，以便进行连接池化和随时间刷新。此外，传统的J2EE平台上的用户需要activemq-ra和activemq-rar模块来支持Jakarta。

此外，许多用户使用快速嵌入ActiveMQ代理以便在单元测试中运行集成和烟雾测试。如果没有启用Jakarta的代理，他们的应用程序测试套件将无法通过。此时，显而易见的最佳前进方式是尽快发布完整的Jakarta版本。

虽然创建过渡客户端的方法旨在减少对最终用户的影响，但最终产生了意想不到的影响，如果ActiveMQ社区采取这种支持activemq-jms-pool、activemq-ra和activemq-rar的Jakarta库的方式，将会延迟完全支持Jakarta的发布。

现代化将持续进行

ActiveMQ 6.x可能会引入基于javax的模块（例如activemq-client-javax和activemq-jms-pool-javax），以向javax.jms用户提供向后兼容性，并允许他们与前进特性保持一致，但这些计划尚未正式确认。目前，javax.jms用户可以使用ActiveMQ 5.18.x中的activemq-client与ActiveMQ 6.x代理进行连接，反之亦然。

Jakarta和Java JDK版本将继续迭代并为编程人员提供价值。HYTE将继续现代化ActiveMQ以采纳能为ActiveMQ用户带来好处的更新和语言特性。

克服对Jakarta的大更新为ActiveMQ未来的变化减少了影响。