As you may know, I was at Devoxx 2011 last week in Antwerp, Belgium, where I have a talk on "What's (probably) coming in
Java Message Service 2.0".
I've uploaded the slides to the project download page:
http://java.net/projects/jms-spec/downloads/download/JMS2.0Devoxx2011.pdf
This essentially covers the same content as the presentation that Reza, Clebert and I have at JavaOne last month, except
that I added a new slide to cover the "simplified API" that we started discussing a week or two ago. I appreciate that
we are still brainstorming on that but I thought it was worth mentioning.
I also reorganised the material to focus on the ease-of-use changes and new messaging features and downplay the rather
less interesting work we've been doing on application server integration and configuration.
There was a lot of interest, with a very good attendance and many questions at the talk and afterwards. Here are some of
the comments that have reached me one way or another (voice, email, JIRA, twitter etc). If anyone reading this wants to
add further comments or elaborate on the comments below please do.
Negative comments:
* There's not much here. It didn't deserve an hour-long talk. Boring. The speaker spent a lot of time on trivial issues.
Yawn.
* The code fragments in the slide were full of syntax errors!
* Providing backwards compatibility is a bad idea as it reduces the scope to make useful changes
* If you're providing backwards compatibility, why are you changing the version number from 1 to 2? This will break
existing OSGI-based JMS applications since OSGI will see the new version number and assume that existing applications
are incompatible with JMS 2.0.
Specific suggestions on existing proposals:
* (JMS_SPEC-36) The callback method BatchMessageListener.onMessages(Message[] messages): passing in an array is so
passé. Need to pass in something like a List<Message> instead.
* (JMS_SPEC-43) The callback method AcknowledgeListener.onAcknowlege(Message message) - I think onSendAcknowledge would
be a better name to avoid confusion with message consume acknowledge when using "acknowledge"
Other suggestions:
* It should be possible to build modular applications in a Java EE environment which use JMS to distribute work from one
module to another. SEDA-style, perhaps. (This was mentioned at the Java EE BOF)
* Marshalling 1: JMS should have support for pluggable marshalling/unmarshalling like in Spring JMSTemplate.
* Marshalling 2: Is it really necessary to create a TextMessage every time you want to send a String? Why not overload
the send method or define it as send(Object) and establish a mechanism to turn an object into a stream? Something like
MessageBodyReader's and MessageBodyWriter's in JAX-RS. As for the receive, I think one way would be to define it as: <T>
T receive(Class<T> c).
* Do we really want to allow a application to be able to specify the physical name of a queue or topic? This will upset
the administrators of our WebSphere MQ installation.
* New feature: Need new API for management and monitoring (queue depth, max queue message size, delete messages etc)
* New feature: Need to support XPath selectors on body of XML TextMessages
* New feature: Need to suppot regexp selectors on body of arbitrary TextMessages
* New feature: Move the send() method onto the Message object.
Nigel