[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] Compatibility breakages in the JMS API versus future development
|
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
