According to the JMS spec, chapter 4.2, Destinations are administered objects, i.e. type-safe resources that "live" in JNDI. The reasoning behind that is absolutely conclusive for connection factories: Decouple the client code from the specific, readily configured implementation. But I wonder, is that also true for the Destinations?
Destinations are a named indirection to the actual addressing scheme used by the provider internally. They have to be configured, of course, but the clients only address them by their name and do nothing else with them but pass them into JMS methods. Connection factories are used to create connections, but Destinations are only passed back to the JMS provider.
I think it would be sufficient to only pass the destination name into those methods, instead of Destination objects that have to be looked up first. That would further reduce the amount of code required and lessen the mental burden of JMS.
Interestingly, this would also permit you to use the same destination name for different JMS providers, which would be very helpful for messaging bridges. Currently you can only pass a Destination to the same JMS provider that the Destination was configured for; you'll have to use some naming scheme to bridge from one JMS provider's destination to another one's.
What do you all think? If I just missed an essential use case, please tell me so!
Regards
Rüdiger