JMS 2.0 Errata
--------------
The JMS 2.1 expert group is still in the process of being formed, and I hope we can start work soon. However in addition
to our long-term work for JMS 2.1 (for release in Q3 2016), we also need to prepare an errata for JMS 2.0, for release
in Jan 2015.
A JMS 2.0 errata is needed to correct a number of errors in JMS 2.0 which can't wait for JMS 2.1 because they affect the
ability of implementers to implement JMS 2.0 and conform to the TCK.
An "errata" is a simple kind of maintenance release intended purely to correct errors in the spec, and which does not
define a new version of the spec or define new features. There will be a new JMS 2.0 spec document and a new set of JMS
2.0 javadocs, but there will be no new compatibility tests and it will not be necessary to make any changes to the
reference implementation or any existing JMS 2.0 implementations.
One of the errors is a bug in the JMS API jar (see JMS_SPEC-161 below). To fix that we will need to release a new
version of that jar. This jar is actually part of the RI, not the spec, but I'm including the bug here for convenience.
The following page explains what an "errata" is
https://java.net/projects/javaee-spec/pages/JCPProcesses
The JCP process for a maintenance release is
https://jcp.org/en/procedures/jcp2#5
This errata is proposed by me, Nigel Deakin, as JSR 343 (JMS 2.0) maintenance lead. Errata releases (and maintenance
releases in general) don't have an expert group. I'm inviting anyone in the JMS community to comment and contribute,
including members of the new JSR 368 (JMS 2.1) expert group, former former members of the old JSR 343 (JMS 2.0) expert
group, and subscribers to users_at_jms-spec.java.net.
Proposed content
----------------
All the proposed changes are already logged in JIRA. For details, see the issue. I will be starting an email thread to
allow us to discuss each.
The following JIRA issues need to be resolved now, and can't wait for JMS 2.1, because they affect the ability of
implementers to implement JMS 2.0 and conform to the TCK:
https://java.net/jira/browse/JMS_SPEC-155
JMS 2.0 introduced incompatible changes to createSession(bool,int)
https://java.net/jira/browse/JMS_SPEC-156
JMS does not adequately define the behaviour of getAcknowledgeMode, getTransacted and getSe
https://java.net/jira/browse/JMS_SPEC-157
JMS 2.0 introduced an incompatible restriction on creating two sessions per connection in J
https://java.net/jira/browse/JMS_SPEC-158
JMS 2.0 introduced incompatible changes to Connection.stop and close and Session.close
https://java.net/jira/browse/JMS_SPEC-125:
Define whether a JMS provider should call reset after sending a BytesMessage asynchronously
There are several other requests for clarifications logged in JIRA but I think we should defer all of these until JMS
2.1 unless they impeded the ability of implementers to implement JMS 2.0.
However given that we are amending the spec I should be able to take the opportunity to fix a few trivial (and
uncontroversial) errors, which I hope will require little or no discussion.
https://java.net/jira/browse/JMS_SPEC-119
Remove reference to password alias
https://java.net/jira/browse/JMS_SPEC-120:
Typo: in example, change .class() to .class
https://java.net/jira/browse/JMS_SPEC-122:
Typos in javadocs for ConnectionFactory.createContext
https://java.net/jira/browse/JMS_SPEC-127:
Incorrect HTML in API documentation
https://java.net/jira/browse/JMS_SPEC-128:
Typo in section 4.14 "Queue"
https://java.net/jira/browse/JMS_SPEC-160:
JMS API source contains self-closing HTML tags
https://java.net/jira/browse/JMS_SPEC-133
Update javadoc comments for QueueConnection#createQueueSession and TopicConnection#createTopicSession
In addition, there's a bug in the implementation of JMSException in the JMS API jar
https://java.net/jira/browse/JMS_SPEC-161
serialVersionUID of JMSException has changed from JMS 1.1 to JMS 2.0
Feedback
--------
If you wish to make comments on any of these issues, please feel free to make them directly on the JIRA issue. In
addition, I'll be starting email threads for each of these issues as I process them, which give an opportunity to make
comments there.
If you know of any additional errors which are either (1) simple typos or (2) errors which need to be fixed now and
cannot wait until JMS 2.1, please say so (and make sure the issue is logged in JIRA). You can reply to this email.
Proposed timescales
-------------------
I'm proposing the following short timescale for this JMS 2.0 errata:
* Nominal start of informal discussions on a JMS 2.0 errata: Mon 24 Nov 2014
* Four weeks for informal discussions
* Maintenance lead sends list of proposed changes to JCP: Fri 19 Dec 2014
* Three weeks for the formal public maintenance review period (extra week because of the holiday)
* Start of EC ballot: Mon 12 Jan 2015
* End of EC ballot: Mon 19 Jan 2015
* Maintenance lead sends final materials sent to PMO: As soon as possible after EC ballot (within 30 days maximum)
* Errata release will take place soon after, whole process expected to be complete by end Jan 2015
What will the version number of the errata release be?
------------------------------------------------------
A Maintenance Release that includes only errata does not define a new version of the spec. An errata update to a
specification document is indicated by including a "Rev level" after the specification version number. In this case, the
specification version number will be "JMS 2.0 Rev a".
The fix to JMS_SPEC-161 will require a new version of the JMS API jar. This again does not define a new version of the
spec. However it does reflect a new version of the implementation, so its version number will be 2.0.1.
Nigel
JMS 2.0 Maintenance Lead