I forgot to say I think we should go through the second option I listed and that is a proper deprecation and removal cycle to give users notice the old API will go away the next major version.
On Mon, Nov 25, 2024 at 3:01 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > I don't think the first two options are a good idea: > > 1) What you are calling deprecation is not actually deprecation as that is > a breaking change. Deprecated features are meant to mean no longer > recommended and may go away but shouldn't just fail with an exception. > Throwing an exception is worse than just deleting it entirely because now > you don't get an error until runtime instead of compile time. > 2) Changing the existing behavior is also not great because it changes > what users are expecting at runtime without a good indication you are doing > so. Users are going to expect that something like that works a certain way > and you've just changed it. > > So based on that I think there are 2 options that make sense: > > 1) Option 3 that you listed - We could just keep them both with the > different interfaces/behavior going forward. However, this only really only > makes sense to me if both interfaces are useful in different ways with > different use cases but I'm not sure they are and could be confusing as you > pointed out. > 2) We could temporarily support both and go through a proper deprecation > cycle and removal. In this case we would mark AyncCallback as deprecated > but still support it with the current behavior, and then for the next major > version (7.x) it would be removed entirely. When deprecating we can point > users to the new API to use and explain the differences and recommend they > migrate. This would give users a notice that it is going away and time to > switch over to CompletionListener before it's gone. That means in version > 6.x we'd end up supporting both until it was removed. > > On Mon, Nov 25, 2024 at 1:26 PM Ken Liao <kenlia...@gmail.com> wrote: > >> Hey dev community, >> >> Would like to get your opinion on this. To make ActiveMQ Classic fully >> support JMS 2.0/Jakarta Messaging 3.1, it needs to support >> CompletionListener interface for specifying callback once the asynchronous >> send is completed. Currently, ActiveMQ Classic has its own public >> interface >> AsyncCallback for client applications to specify the callback. However, >> the >> behaviour of AsyncCallback is not JMS 2.0 compliant and it is specific to >> ActiveMQ. >> >> In my opinion, it will be a confusing experience for users because there >> are two mechanisms for specifying callbacks and I wonder if there are any >> advantages of using AsyncCallback over CompletionListener. Either: >> 1. Deprecate AsyncCallback (throw exception) at the release where we >> support CompletionListener. >> 2. Change AsyncCallback behaviour to align with CompletionListener at that >> release. >> 3. Keep supporting these two different interfaces/behavior going forward. >> >> Personally I am advocating for 2 but would like to hear what the community >> thinks and check if I am missing something. >> >> Thanks, >> Ken >> >
