Jakarta Messaging Next

[dblevins]

This issue serves as effectively the JSR replacement, intended to give a high-level view of the Jakarta Messaging 3.0 road map and goals.

• Specific proposals should be filed separately and linked here.
• Only curated proposals that have had community discussion should be listed here.
• It is expected this issue will mutate and be updated frequently.

Road Map

The community is still bootstrapping initial discussion. All items below should be viewed as tentative.

New Features

• Annotation-Based API for Consuming Messages Annotation-Based API for Consuming Messages #243
• CDI Message Consumers CDI Message Consumers #244
• CDI Stereotypes CDI Stereotypes #245
• Property Conversions Property Conversions #246
• JSON-B Messages JSON-B Messages #247
• JAXB Messages JAXB Messages #248
• MessagingClient MessagingClient #249

Enhancements

TBD

Bugs

TBD

Resources

• Jakarta Messaging 3.0, Redefining JMS | JakartaOne Livestream

Submit a Use Case or Proposal

For information on how to submit a use case or proposal, file a new issue labeled either use case or proposal. Do not file one issue labeled with both. See this for more guidance:

• https://github.com/eclipse-ee4j/jms-api/wiki#use-cases-and-proposals

[m-reza-rahman]

This looks good. I'll add more (lower priority) issues as soon as I can. Did you happen to look through the old issues from JMS 2.1? Nigel and I had filed quite a few as backlog items. If not, I can track those down and just link them?

Reza Rahman
Principal Program Manager
Java on Azure

Please note that views here are my own as an individual community member and do not represent the views of my employer.

[vongosling]

Great, I am very happy to hear the next step for previous JMS specification, especially the change from https://github.com/eclipse-ee4j/jms-api to https://github.com/eclipse-ee4j/messaging-api. @dblevins I wonder do you consider to import the connector, event or streaming support, some works are made by OpenMessaging(https://github.com/openmessaging). if any possible, we could work together in messaging field :-)

[arjantijms]

I changed the title to 4.0, as we already delivered 3.0.

Continuing this though, now that EE 9 has been delivered, should we start to set dates for these items? Anyone eager to start doing a prototype implementation for some of these things?

[dblevins]

Switched it from 4.0 to "Next" as we could potentially deliver some of these things in a handful of smaller releases: 3.1, 3.2, 3.3 and iterate.

On prototyping, certainly, anyone is welcome to start! On my end we'll be 100% focused on getting TomEE Jakarta EE 8 and 9 certified before we tackle new spec work.

[OndroMih]

Hi @vongosling,

I'm reacting to your comment here and to your email in https://www.eclipse.org/lists/jms-dev/msg00151.html as well.

First about your concerns about container environment. I believe you don't need to be afraid that JMS would require running in a container for any functionality. The idea is only to make it easier to use MDBs if the application already runs in a container. A new Annotation-Based API aims to replace the cumbersome MDB API, CDI integration should make it possible to specify the scope of MDBs and also clarify how CDI beans are injected into MDBs. All in all, this doesn't add any substantial functionality, it aims only to simplify and clarify existing features.

However, it would also be interesting to add support for something new that's missing. I agree that support for connectors and streaming would be useful. For streaming, I would like to avoid having to rely on some reactive API if possible, or at least rely on Java 9 Flow interfaces and let people use a reactive library that combines publishers and subscribers. MicroProfile reactive messaging already has support for both connectors and streaming so we can look into whether and how we can bring some of it over to Jakarta Messaging. MicroProfile has some nice things, like channels, which can be mapped to connectors to external systems (e.g. to a JMS topic) or to internal lightweight topics to connect and chain publishers and suppliers. On the other hand, what I don't like about MicroProfile RS is the complexity of the reactive API, which is hard to get around even for people who have experience with reactive programming.