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

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Sorry, I meant this repo:

 - https://github.com/jakartaee/messaging-proposals

Add any and all ideas there.  Try to break them up and have one folder focused on a simple aspect vs a massive folder with everything.  Makes them easier to discuss, digest and get incremental agreement.

If someone adds an idea you like but you want to change it slightly for any reason, go ahead and copy the folder with a slightly new name (a number is fine) and make the changes you want.

No reviews required to commit to that repo.  Have at it.


-David


> On Mar 4, 2025, at 5:33 PM, David Blevins via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
> 
> 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
>>> 
> 
> _______________________________________________
> messaging-dev mailing list
> messaging-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org