[
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
|
Any and all ideas welcome. People can start directly adding them here:
- https://github.com/jakartaee/messaging
If we start to get a lot of submissions we can maybe organize them into subfolders, but for now I say go for it.
Agree that if there are, let's call them "mappable breaks", where apps could be ported with a fancy bytecode tool that would be much easier to add near term. I may have misunderstood the automated part though, so do clarify if I missed the mark.
-David
> On Mar 4, 2025, at 5:23 PM, Scott Stark <starksm64@xxxxxxxxx> 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
>>