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

[Scott Stark <starksm64@xxxxxxxxx>]

There is nothing wrong with having two concurrent specifications to
explore both minor updates and what is needed long term. I still would
have a concern that minor updates should be done in a backwards
compatible manner given the age of the API. I would first want to look
at what would be the smallest and yet interesting update and look to
restrict that to differences that are easily portable from the legacy
API such that it could be automated. Maybe that is what Reza means by
a "Lite Profile" with a fresh API.

On Tue, Mar 4, 2025 at 5:51 PM David Blevins <dblevins@xxxxxxxxxxxxx> 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
>