How much can we break in the API on future Messaging specifications?
We have a 28-30 year old ”legacy debt" in the JMS API, and there are things that are now considered old fashioned. Java Language itself evolved quite a lot obviously, and Messaging itself has changed.. (streaming, asynchronous natures, HA Zones... Cloud replicas, etc.. etc.).
Besides the old fashioned usage in Interface, you also have the heavy semantic inference and dictation of what a messaging system is from the spec itself. It would be nice to make things lighter and more compelling for new systems to implement and easier to digest from a new audience.
We need to move on from this 28 years old legacy and I think there's still space for a standardized API within Jakarta..
I made a car analogy the other day about this: you can certainly make an Old VW Beetle look shiny and new, but it will still be a car from another era. While you can certainly use it and have fun with it, it will never be a modern car, no matter what engine you put in that car.
We could of course still invest in the current spec for now, but I think we should aim for something more modern as well. I would love to listen to other people's ideas on this matter.
Thank you and hope we are able to make something new in this area.
Clebert Suconic
