JMS: only java, it is a specification
AMPQ: universal, it is a protocol, it is open standard for messaging
JMS doesn't define a protocol.
JMS is an API and AMQP is a protocol.
AMQP supports 4 message models: Direct, Fanout, Topic, Headers
JMS supports 2 message models: P2P (Point to Point), Publish/Subscribe
AMQP supports security i.e.SASL, TLS
JMS specification does not support security and hence implementation is left with JMS provider.
Message Format Type:
JMS: BytesMessage, MapMessage, ObjectMessage, StreamMessage and text message.
AMQP: binary.
AMQP: Supports transactions (across message queues) and distributed transactions (XA, X/Open, MS DTC)
The main difference with JMS (which is a Java EE specification and API) is that AMQP is just a binary wire protocol which was designed for interoperability between different vendors and platforms. As long it's AMQP complaint, changes at the broker level are not needed.
In other words, you can use a pure Java JMS client to communicate with the AMQP protocol if the messaging server supports it.
Why AMQP is better than JMS
While there are implementations such as ActiveMQ, HornetQ and SonicMQ, that offer some level of cross products interoperability, that is being done thru proprietary protocols, APIs, and client libraries. You can't just replace one broker with anther without go to your code, as it was the case for Java applications. We're deep coupled here to a specified broker that can't easily replaced, if that's possible at all.
AMQP is around a binary wire protocol which was designed for interoperability between different vendors and platforms. As long it's AMQP complaint, changes at the broker level are not needed.
The biggest benefit over JMS is not being locked into one language. AMQP doesn't care if your front end is in Ruby and your back end is in Java. It really makes it much easier to integrate diverse applications into a single stack. JMS is a lowest common denominator because it was designed as an abstraction layer over brokers that already existed. As a result the native APIs always were going to have a richer feature set.
By contrast AMQP, was not designed to layer over existing brokers, but to start with a fresh sheet of paper to provide the desired features for messaging using an open protocol. As a result, AMQP is not constrained by what existing brokers do or do not offer, instead it's design goals have been dictated by what do messaging users want? AMQP is a modern intepretation of what a messaging protocol should offer...both in it's 0.9.1 and 1.0 variations. That's why AMQP is very much not in the same "lowest common denominator" boat as JMS.
(...also crucially different...AMQP provides mechanisms for broker-specific extensions that don't break the overall protocol. So you get the best of both worlds, a common protocol with optional extensions you are free to utilize or not. Which is unlike JMS, where you HAVE to use a completely proprietary native API if you want those extensions. With AMQP you use AMQP, no matter what subset of it's features you want.)
Another key differentiator from AMQP, is that JMS clients are not cross-compatible even within Java. With rare exception you can't use vendor A's JMS client with vendor B's broker. And their adherence to the JMS API interfaces is even loose enough to the point that it's not always plug and play to change clients in your app either.