Support Jakarta Messaging 3.0 API

Open acogoluegnes opened this issue 3 years ago • 0 comments

Background

RabbitMQ JMS Client 2.x supports JMS 1.1 API, it requires Java 8. This is the current version of the library.

JMS 2.0 introduces API changes and some new features. A JMS 2.0 client library must implement these changes. From an application developer's point of view, upgrading from JMS 1.1 to JMS 2.0 is transparent, minus some minor changes in the semantics of some methods. JMS 2.0 requires Java 8.

In 2018, as part of the Java EE to Jakarta EE migration, JMS became Jakarta Messaging, and Jakarta Messaging 3.0 was released. It requires Java 11. The name of the Java packages changed, so JMS 2.0 and Jakarta Messaging 3.0 are not compatible. Jakarta Message 3.0 does not bring any other changes though, so moving from JMS 2.0 to Jakarta Messaging 3.0 does not require much effort for a JMS client library.

Note: Jakarta Messaging 3.1 is available, with minor tweaks.

Spring 6.0 (not released yet) will support Jakarta EE, and so Jakarta Messaging.

Impact

The RabbitMQ JMS Client Library is a proven solution to migrate legacy systems to RabbitMQ with minor changes to existing JMS applications. The library can be used on its own or with Spring JMS support.

The implementation of JMS 2.0 does not seem to be essential to users, as it's been requested only once in the last 6 years IIRC. The new features may not be critical and Spring JMS is a good substitute for the API improvements.

Staying compatible with Spring does matter: questions and issues from the community channels reference Spring often. It seems appropriate to keep up with Spring 6.0 by supporting Jakarta Messaging 3.0.

Possible Roadmap

It's not realistic to go only with Jakarta Messaging, so we'll have to maintain 2 branches:

2.x: JMS 1.1 or JMS 2.0, Java 8 or more.
3.x: Jakarta Messaging 3.0, Java 11 or more.

It may be technically possible to support JMS 2.0 in 2.x, but this should also let the choice to use JMS 1.1.

A possible implementation path would be to support JMS 2.0 in 2.x and supporting Jakarta Messaging 3.0 in 3.x would be just a matter of renaming packages.