[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [messaging-dev] [jakartaee-platform-dev] Compatibility breakages in the JMS API versus future development
|
- From: Reza Rahman <reza_rahman@xxxxxxxx>
- Date: Tue, 4 Mar 2025 20:43:08 -0500
- Delivered-to: messaging-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/messaging-dev/>
- List-help: <mailto:messaging-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/messaging-dev>, <mailto:messaging-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/messaging-dev>, <mailto:messaging-dev-request@eclipse.org?subject=unsubscribe>
- Ui-outboundreport: notjunk:1;M01:P0:1+Uoz+Qd+fM=;ya7vizaHLOU70z2cXoEGTZsf9yK IBOcPrN75JezpF5C65dhHvf1zVLnaMASozd1Im1b+Gy18Qr38xCg9Da5ej/K5xAxdNgY+er// gMNH14HBN1n8cUzfPxAGKGgrhADBZLaFlPFrcRDNu5VZ6A0ntNZnElUijEOeZhLwjt09ul5V9 R7TqsYgFKsP22NtXIjaXw2uAQ2F36b/6E2mVVIhZtA5lG7XT887PS5Fs/L6955ioFXPgyiNzZ sFV6SW/cfVgOLr3As7o/CSQv7CkhNVquBKDVfO24hX64/csELREDSQ8Ky0wi8nsMZupAjKs7j 46yIYnH0FxeU76BWoAjeON8q8WUAFBq23HLAtRY5ZzMJEwnd1folu3M1L6KYWDKbJhuOubyoz DBX5dd9JvQjwl12oWpsI8ssUOukqW/6wnecoXlH4EyQKcRsKNNs/6dU/xXkEuslUgy9wYBxfI aPZQZGyoApUbWdZpoTu04isG6MW3GIkuHElkRsICTAYfyTqHIumxlvGZxjJ0+p7Qsoyc/CwXk MzFLxoMONtQqkX5SG1vqWFLcgP4cuMT53sTWPXn8Xd3epuGCQ9bmWzqAQBneKjVnhRjlmuzNV PoFZfyzZH44wyZuwYEDtOjIim/bwBeIQ8V4s81uNMs/sKoZEiXmyeQvgGgSdGl33J7x+3SBJl 8HYyvnuBuoitsXIuEaab5gJQHWnVpKdfUx2bX3XT+IgVs0T/ky+xAiwzlfwJFEsnDPxnjyDov rnUizNevO4y9DPbSzO8P27tksNjsXe0p7QJx3rYXBVGVj6OzIIuzoPEE7Z+DHPXFEIEM1iQh8 vnAVExUB3HJjd1KtGiytikP8EhpQuJJ1FrhtfQV85LxWf8b/ITtCF8gV6RQkc5gAoSP9d5n9M 6Er/YdClGYUnblwnN0Nq5cX0NahIrxMG2Y7T2kt7G5cEpBfqqcNud9agEVYFIh0Iar8xP5Fry 5BhqUUdwS1edD6DWN4gXpM078m6hv9tIPwZEc1pYxkxnurC9BL55wgBRLNbZZWEbBkeZojvF9 Mv5bO77nsJeX/OGx8qlA+P9EBAGqIRbLzTM23JFMliAIc2oQWIwCLSdybDHBvHt1CnJ/gPOrp iNF57jnHxCNeFqvf/63hwboWj3uw0HC7g1HTKLLAFB48wdN40kr+nnVnhuu9FKMkbW1CAJVtV buk2IC97t/B9jS87WTbPQZ04y4uJF8cRL67G4BT61MPDLFtakxHktOamQyrvYcrSsBYY+P0gd AmgN2Hj9QmOSebOceeWOnIGfJyIvkClP33oq7NabUEsAc8kvLA98UfEcO1qSKvbyjIiuRsG7K Oajs0217OvB32BXE/40oHiGmwEfUqMuJxFAuyJL0TnOmY2ZTD2DIVPm6xu6jnxPmeDdPHKvhO 6iI5yZUvdShoR8cVj2cX3S3QADEsLYQ6tDwycmp3sug/prfKoAt53A7XKp
- User-agent: Mozilla Thunderbird
Indeed that's what I mean and hopefully it is a sensible market message
and also sensible technically.
I have to look at a detailed proposal, but my hope is that "Messaging
Lite" could essentially be a net new API that ultimately supersedes the
old API once it gets a bit of traction.
The old API could be completely disconnected from Lite. There is no hard
and fast rule that says a Profile needs to be a strict subset.
I think trying to leverage the brand is a good thing to do. I suspect
trying to successfully establish an entirely new brand in a space that
is seen as mature/stable is tougher than anyone imagines.
On 3/4/2025 8:23 PM, Scott Stark via jakartaee-platform-dev wrote:
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev