I've created the following JIRA issue to cover the work to devise a new simplified API.
http://java.net/jira/browse/JMS_SPEC-64
The JIRA issue describes some goals for the API:
* To reduce the number of objects needed to send and receive messages, and in particular to combine the JMS 1.1
{{Connection}}, {{Session}}, {{MessageProducer}} and {{MessageConsumer}} objects as much as possible.
* To take advantage of the fact that this is a new API to simplify method signatures and make other simplifications
which cannot be made to the old API because it would break backwards compatibility.
* To maintain a consistent style with the existing API where possible so that users of the old API feel it to be an
evolution which that can learn quickly.
* To support, and offer benefits to, both Java EE and Java SE applications.
* To allow resource injection to be exploited in those environment which support it, whilst still offering significant
improvements for those environments which do not.
* To provide the option to send and receive message payloads to be sent and received directly without the need to use
{{javax.jms.Message}} objects.
* To remove as much as possible the need to catch {{JMSException}} on method calls
* To be functionally complete. The old API will remain to provide backwards compatibility. However the new API is
intended to be functionally as complete as the old JMS 1.1 API. Users should not need to switch back to the old API to
perform an operation that is unavailable in the new API.
As you know we've had quite a few discussions on this already, and as promised I've written up a proposal. This is
described in a pdf document at:
http://java.net/downloads/jms-spec/Simplified%20API/JMS20SimplifiedAPIv1.pdf
with a corresponding set of javadocs at:
java.net/projects/jms-spec/downloads/download/Simplified%20API/jms-2.0-javadoc.jar
Please take a look and make comments.
Comments are welcome on anything I've written, but I should say from the outset that some aspects of the proposals are
further advanced than others. In particular I haven't suggested how we might exploit the new API using CDI. I hope that
the proposed API makes this easier to achieve but I hope to have a discussion about what we might do.
The proposals also suggest a simple API for sending and receiving message payloads directly but I think this needs some
more work.
Thanks,
Nigel