There seems to be some confusion on what the plan is for JMS 2.0 support in 5.x so I figured it was worth starting a discussion on it.
First, targeting a complete implementation of "full" JMS 2.0 support for 5.17.0 is not very realistic in my opinion. I think 5.17.0 needs to go out faster than 5.16.0 did as for one thing it is starting to get annoying to have to use JDK 8 to build it. If JMS 2.0 support is going to happen that's probably going to take a few releases along the way with increasing functionality for each one and there is still a discussion that needs to happen on what will actually be done and the effort level. The main level of effort is dealing with the new shared subscription semantics. For example, in order of increasing effort: *1)* We could just add basic API compatibility with the JMS 2.0 jar but don't really implement many features at all (maybe have unsupported exceptions thrown if a new method is called) which i think was the goal of 5.16.1. Note that this isn't really buying much as a user can simply use the JMS 2.0 jar now with 5.x and just not call the new methods (which is what I personally do) *2)* We could have the Java client fake it by using Virtual topics to create shared subscriptions. So if a user calls off to the shared sub api call it would just subscribe to the matching queue it needed. The downside to this is it's done all client side so would only work for the Java client and not any other open wire clients and is pretty hacky. Seems better to just have the user use virtual topics natively than this way. *3)* Another approach could be to add full JMS 2.0 support to OpenWire and upgrade the client/server to the new version but use Composite destinations or Virtual topics on the server to provide the functionality. The idea being when the server receives the new openwire commands to create a shared subscription it fakes it by leveraging the composite destination or virtual topic feature to mimic the behavior. The main functionality to add would be client side, openwire itself and the management/tracking logic on the server side to map shared subscriptions to composite destinations/virtual topics. *4)* We could add true native support for JMS 2.0 to the client (openwire) and server (treat shared subs/durables as their own thing in the broker logic and also in the different storage options) and this would take by far the most effort to do correctly. In my opinion number 3 seems the most viable if JMS 2.0 support is really desired as the level of effort wouldn't be as bad compared to trying to do full native support as described by number 4. Simply leveraging composite destinations behind the scenes seems like a decent solution on the server side as we should be able to get the desired behavior and spec compliant. Alright, all of that being said, while it would be kind of nice to have JMS 2.0 in 5.x to give people options, I still lean to the idea that it would be a better use of time to just work on improving the migration and feature parity of 5.x with Artemis instead of adding JMS 2.0 support as Artemis already supports it. If migration is easier and if all the main 5.x features people care about work in Artemis then people could just migrate to Artemis.
