Thank you to everyone who has submitted a list of their priorities for JMS 2.0. If anyone else wants to add their own
priority issues to the list, please do so (please only suggest issues that you consider a priority). If you're simply
waiting to see what the others come up with, that's fine too.
Here's a high-level summary of the topics raised so far. I've added the name(s) in brackets afterwards of the person(s)
who raised each topic, to help you identify the topics you raised. Since I've re-phrased some topics in my own words,
please let me know if you think I've mis-represented you. Also, please let me know if you think I've missed an issue you
raised.
I've added a few comments in [square brackets] where I think that a suggestion raises questions or issues, but in
general I've tried not to act as judge of any of these suggestions at this stage. Everything is still on the table.
So what's the next step? I think we need to get these issues (and I know more will keep arriving) divided into two groups:
(SHORTLIST) a shortlist of issues which we will definitely discuss more over the next few weeks and
(DEFER) those which we will defer until later. Unless there is a clear consensus that an issue can be dropped, we'll
keep this on the list for later consideration.
(I propose that issues already mentioned in the JSR proposal go directly into the shortlist, and are marked (SHORTLIST)
below (so you can take it as read that we'll be drilling down into the details of those shortly)).
So please let me know what you think of these various issues (including those marked as (SHORTLIST), but particularly
those which are not). Feel free to use the +1 or -1 convention (or (SHORTLIST) and (DEFER)). If you would prefer we
simply drop an issue, please say so. If you're name is already down as supporting an issue then there's no need to
endorse it again.
Note that I don't see this as a vote; I'm looking for consensus but will make a judgement based on the responses.
Also feel free to ask for clarification of what a particular issue is about, or to state why you have expressed the view
that you have.
Finally, I haven't covered proposals made in JIRA here. But I haven't forgotten them and will make sure these are
considered in due course.
Nigel
General, overriding issues which need to be kept in mind
--------------------------------------------------------
* Any changes need to be backwards compatible: applications which are written to JMS 1.1 will continue to work (Reza).
* We need to make sure that we don't lose sight of the need to be able to use JMS outside of a Java EE environment: Java
EE must not be a requirement. (Adrian/Shivajee)
* One of the reasons why JMS has been successful has been its small, simple API. Let's not see this compromised just for
the sake of change (Adrian/Shivajee).
[My reaction is to accept all three of these as principles we should follow. Any objections?]
Major new API features
----------------------
* We should provide a modern, easier-to-use API, probably using annotations and CDI (Nigel, John, Reza, Julien,
Clerbert, Masoud). There seemed to be a variety of ideas of how we might do this, and we will need to explore these in
detail. Whilst I think we mostly see this as a feature for Java EE containers, there seems to be interest in offering
features to those using a Java SE environment as well. (SHORTLIST)
* There was a view from several of you that we should work to improve or replace MDBs as a way to asynchonously consume
messages in a Java EE container. (Emran, Adam, Clebert, Julien). There was also a suggestion that we remove the
restriction that prevents a application calling MessageConsumer.setMessageListener() within an EJB or web container
(Clebert). This is all closely-related to the previous issue. [Given that MDBs are already defined using annotation,
I'd like to understand better what it is that people feel are the problem with MDBs. I'm aware that the introduction of
CDI observers in Java EE 6 means that we have two alternative means of async notification: events and messages, and two
alternative types of callback: observers and message-driven beans, which poses the question of whether they can be
combined] And as with the previous issue, there was a suggestion that we would try to offer features to those using a
Java SE environment as well. (SHORTLIST)
Better integration with Java EE
-------------------------------
* We need to standardise the interface between a JMS provider and a Java EE application server, to allow portability of
JMS providers between application servers. (Nigel, Adrian/Shivajee). The frontrunner here is to mandate the provision of
a JCA resource adapter, though an alternative may be to extend and make mandatory the existing Chapter 8 API. (SHORTLIST)
* Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities", which defines API for use by
application servers, including ConnectionConsumer, XAConnection, XAResource (Adrian/Shivajee, Nigel). This is optional
and has no compliance tests. Should we make it mandatory or simply drop it? If we make a JCA API mandatory is this still
needed? Experience has shown that this chapter leaves some issues undefined and that improvements would be necessary if
we decide not to drop it. (SHORTLIST)
* Clarify how the JMS provider should interact with Transaction Managers. In particular, the responsibilities of the
JMS Provider, the TM and the App Server during recovery need to be clearly defined. (Adrian/Shivajee) (SHORTLIST)
* We need to clarify the relationship between the JMS and other Java EE specifications. This is mainly a documentation
exercise, especially for those methods which are forbidden or modified in a EJB or Web container, but there are some
ambuguities, especially when the transaction context is undefined. (Nigel). (SHORTLIST)
Other API changes
-----------------
The following, more specific API issues were raised:
- The API should make less use of unchecked exceptions (Reza). Reza point out that in many cases the application doesn't
know what to do when a javax.jms.JMSException is thrown, so for methods to declare that they throw a checked exception
is not always helpful. [We would need to maintain backwards compatibility (which Reza also states the need for), which
would limit the scope to change things. Also, some providers do rely on throwing exceptions to notify the client that
they need to retry an operation, perhaps the real issue is that this is non-standard. ]
- Security (Emran). Emran mentioned this in passing. [This is a large topic, and one which JMS has hitherto said little.
I've separately asked Emran to clarify what he has in mind. ]
- Compression/decompression (Emran). I take it that this is a request for an API which would allow a client to define
whether a message is compressed in transit. [JMS providers are currently free to decide for themselves whether to
compress a message, and many do, so the question here is whether we need to allow clients to control this via the API
rather than via provider configuration features. ]
- Timed messages (ability to send a message which the provider will deliver at a configured time in the future) (Emran)
- Sending/receiving messages in batches (Emran, Clebert).
- API to asynchronously send a message, with the server invoking a callback to acknowledge receipt (Clebert)
- Improve existing API method Connection.createSession(boolean transacted, int acknowledgeMode). Can we have a single
argument? (Julien) Do we need a different API for use in a BMT/CMT transactional context? (Nigel)
- Add support for message consumption from the same session by multiple threads. This implies the need to be able to
acknowledge individual messages. (Adrian/Shivajee)
- Make use of new language features such as Generics (Adrian/Shivajee). [I've separately asked Adrian/Shivajee to
clarify what they have in mind.]
- Deprecate JMS 1.0 Queue and Topic specific interfaces in favor of JMS 1.1 unified interfaces (Adrian/Shivajee). Adding
the @Deprecated annotation is easy enough, but do we want to formally announce that we will remove them from a future,
non-backwards-compatible, version of the spec?
- Decouple the creation of a Message from a Session (Adrian/Shivajee). [I would comment: what alternative mechanism did
you have in mind?]
- Ability to send objects directly, without need to wrap in a javax.jms.Message (John)
- We need to "scan all of the implementations" and look for features to standardise in the spec. (Masoud) [If you're
offering to do this, please do.]
- Standardise the "connection string" to define server IPs, timeouts, etc, as in ActiveMQ (Julien). Currently JMS
doesn't define a connection string, and expects any connection config to be defined in the connection factory which is
currently vendor-specific.
Quality of service (QoS) features
---------------------------------
- Extend the spec to define clustering and failover behaviour (Emran, Julien). [The existing spec deliberately leave
this to vendors to define their own behaviour; perhaps what we should be focussing on is addressing areas where
different clustering and failover behaviour hinders portability of applications between providers. For example, whether
a failover causes a JMSException, or causes the transaction to be rolled back.]
Support for Java SE environments
-----------------------------
- the API should not rely on JNDI for creating connection factories and destination objects (Julien, Clebert). [I think
the issue here is not so much JNDI but the idea that the creation of connection factories and destination objects is
provider-specific and non-portable and so should not be done directly by the application. We would need to consider
whether by removing this principle (presumably for Java SE clients only) we would be reducing the portability of
applications.]
- the API should mandate pooling of JMS resources when used in a Java SE environment (Julien). [I suppose the issue here
is the extend to which we are expecting a JMS client to itself be a kind of lightweight container providing services
such as connection pooling that are already available in, say, the Java EE application client container.]
- define the concept of a JMS "container" for use within a Java SE environment which would offer various services,
including CDI (John)
Supporting cloud-related features in Java EE 7
----------------------------------------------
- We need to monitor the activities of the Java EE platform EG and identify any changes to the JMS spec that are needed
to support cloud-related features in Java EE 7 (Nigel). Since two members of the JMS EG are also on the Java EE EG (Reza
and Adam) I hope they can help with this. I'll also follow the Java EE EG and keep in contact with the spec leads.
(SHORTLIST)