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

[Reza Rahman <reza_rahman@xxxxxxxx>]

Also a very sound idea if the resources are there to do the work. The
benefit of this approach is that it reassures current customers/gives
them something usable right away after a very long time while also
creating a broader expectation of something much more interesting in the
near future.

On 3/4/2025 6:50 PM, David Blevins via jakartaee-platform-dev wrote:
> I agree it's worth looking at with a large caveat that we should do this after we get some of the low hanging fruit out with the existing API.  Specifically the items around json/xml message marshaling, annotation api, property conversions, etc.
>
> Those would all make a big difference to people on the current API and could be done near term and easily be implemented by everyone now.  Reimagining the API would likely take quite a while and be pretty contentious.  Not that it wouldn't be worth investigating, just that we'd be further delaying some already delayed work.
>
> Perhaps this as a tentative strategy:
>
>   - Messaging 3.x : continues, backward compatible, with backlog items implemented
>
>   - Messaging 4.x : sky is the limit, not backwards compatible
>
> Thoughts?
>
>
> -David
>
>
> > On Mar 4, 2025, at 3:05 PM, Scott Stark via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
> >
> > I would say the messaging project is free to deprecate the existing
> > JMS API/spec and have the platform put it into legacy mode for future
> > deprecation as well. Jakarta Messaging Next can be a completely
> > different specification from my perspective.
> >
> >
> > On Tue, Mar 4, 2025 at 4:57 PM Clebert Suconic via
> > jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> 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
> > _______________________________________________
> > jakartaee-platform-dev mailing list
> > jakartaee-platform-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev