Re: [messaging-dev] [jakartaee-platform-dev] Compatibility breakages in

[Matt Pavlovich <mattrpav@xxxxxxxxx>]

I’d be onboard with a new API— (ie new packages and classes) as a better approach vs refactoring.

This would allow providers to continue to provide support for the existing API in the same classpath.

Thanks,
Matt Pavlovich

> On Mar 4, 2025, at 6:07 PM, Reza Rahman via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
> 
> No doubt Jakarta Messaging is way overdue for a real revamp. The brand
> is still strong enough but honestly the API is not any more. Microsoft
> would be very supportive of evolving the old API a bit and trying to
> create a new "Lite Profile" with a fresh API. We would also be fine just
> taking a fresh look at the whole API and break backwards compatibility
> once in almost 30 years. I believe it will create market excitement.
> Something definitely needs to be done if the existing Jakarta Messaging
> products want to compete with the likes of Kafka.
> 
> In terms of the norms, Jakarta EE does not have the same extremely rigid
> stance on backwards compatibility as Java EE. If there is consensus to
> just do a complete revamp once, there is nothing stopping it in
> procedural terms. If your proposal has legs, Microsoft will even help
> make it happen with it's own resources.
> 
> Hope this helps.
> 
> On 3/4/2025 5:57 PM, Clebert Suconic via jakartaee-platform-dev wrote:
>> 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
>> 
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> messaging-dev mailing list
> messaging-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org