Over the last few months the topic of backwards compatibility has come up and I promised to find out whether or not
there were any general Java EE guidelines that we need to confirm to.
I've now had several discussions with the Java EE platform spec leads, and the other Java EE spec leads at Oracle. It
appears that whilst there's not much written down, the Java EE platform has been following some fairly strict practices
in deciding what types of change are permitted when defining a new version of a specification.
In conjunction with my colleagues I've written down this general Java EE policy and published it on our wiki here:
http://java.net/projects/jms-spec/pages/CompatibilityGuidelines
I'm a bit surprised this wasn't written down before, but this does seem to be a longstanding policy. It's apparently
only because I'm a new spec lead that I have needed to get this written down.
In terms of JMS 2.0, I think this policy does allow us to extend the functionality of JMS by adding new methods to
existing interfaces. We don't need to define a completely new set of interfaces.
However it does mean that we can't do a number of things that we (and I) had previously proposed:
* We can't use the @Deprecated annotation. We must simply add comments in the javadocs and spec.
* We can't make the domain-specific interfaces (QueueConnection etc) as "proposed optional" because they don't relate to
a major area of functionality which has become obsolete in the way that, say, EJB entity beans do. We can write whatever
documentation we like to steer users towards the domain-independent interfaces (Connection etc) but we're stuck with the
old interfaces indefinitely.
* We can't change JMSException to becoming a RuntimeException because it would change its behaviour in certain cases (as
I mentioned last week).
* Since we can't ever remove existing methods, or even mark them as @Deprecated, we are stuck with the existing four
Session constants (Session.AUTO_ACKNOWLEDGE etc) for the foreseeable future, so introducing four new session mode enums
would probably serve only to complicate things.
I'll make appropriate comments on the relevant threads for these issues.
Nigel