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 >
