Starting with 5.0.0, the dependency to the JMS API was changed in spring-jms for 2.0.
Spring documentation and/or javadocs might make clear that this does not mean that spring-jms 5.x actually requires the provider used to implement 2.0.
In my case, I am evaluating the impacts to upgrade some applications I have from spring 4.x to 5.x. For other external dependencies/impacts like for instance JEE APIs like servlet-api or JPA, Spring documentation make this clearer. For instance, LocalContainerEntityManagerFactoryBean's javadoc make it clear that JPA 2.1 is required. As I currently depends on a JMS provider (Oracle AQ) that only implements JMS 1.1, to be sure I would not have issues I had to download spring-jms code and search in it for calls to ConnectionFactory.createContext. Only after doing that I was able to see that there is no such call, and was able to conclude (yet without 100% certainty) that the upgrade of the dependency to 2.0 must have been to allow the spring-jms ConnectionFactory decorators to be 2.0 compliant.
Spring Framework Reference documentation and/or some javadoc (maybe the one of @EnableJms) might make this clear.
Technically speaking, we require the JMS 2.0 API to be present on the classpath now. At the same time, our common execution paths at runtime still operate according to JMS 1.1 rules, with just optional calls to certain JMS 2.0 methods in certain configuration scenarios.
In practice, this means you'll have to upgrade your JMS API jar to 2.0 for your Spring setup but should be able to run against a JMS 1.1 provider at runtime, being bound to the JMS 2.0 API jar and simply not implementing the new 2.0 methods (which Spring isn't using by default anyway). While such a combination is not recommended, we see the need for it in upgrade scenarios, so we should also document it as "supported under certain constraints".
Many parts of Spring's JMS support are effectively still JMS 1.1 compatible, just happen to be compiled against the JMS 2.0 API. It's only really CachingConnectionFactory and co where actual JMS 2.0 runtime dependencies emerge, but even there only to the JMS 2.0 API, still allowing it to be bound to a JMS 1.1 based driver at runtime (as long as the 2.0 API is present).
I've added corresponding documentation notes to several places, in particular the javadoc of the ConnectionFactory decorators and the JMS introduction in the reference documentation.