Last week I circulated a list of errors in JMS 2.0 that which can't wait for JMS 2.1 and which need to be fixed in an
errata release. I've created a wiki page that contains information about the errata release and the issues that it will
address:
https://java.net/projects/jms-spec/pages/Home#JMS_2.0_errata
I will now work through these issues in turn.
The first issue is
https://java.net/jira/browse/JMS_SPEC-161
(serialVersionUID of JMSException has changed from JMS 1.1 to JMS 2.0)
The problem is that the serialVersionUID of javax.jms.JMSException has changed from JMS 1.1 to JMS 2.0, which means that
if an instance of this exception is serialized using JMS 1.1 it cannot be deserialized using JMS 2.0 or vice versa.
Although this class is defined in the JMS specification, its implementation is, strictly speaking, part of the RI. We
can therefore fix this issue by fixing the reference implementation and releasing a new version of the JMS API jar to
Maven Central. I am planning to do this now without waiting for the errata release. The new jar will be version 2.0.1,
where the ".1" is an implementation version. The spec version remains unchanged at 2.0.
I've recorded the fix details in the MQ JIRA
https://java.net/jira/browse/MQ-359
Fix details
-----------
**Unless you're particularly interested in the details of this bug, you can stop reading here.**
The cause of the change was that I removed the "synchronized" keyword from one method on JMSException, since it was not
needed. However this had the undesired side-effect of changing its implicit serialVersionUID, which meant that instances
serialized using JMS 1.1 could not be deserialized using JMS 2.0, and vice versa.
Since these classes implement java.io.Serializable it is reasonable to try to preserve serialization compatibility. I
have therefore fixed the issue as follows:
For all exceptions that were defined prior to JMS 2.0 (IllegalStateException, InvalidClientIDException,
InvalidDestinationException, InvalidSelectorException, JMSException, JMSSecurityException, MessageEOFException,
MessageFormatException, MessageNotReadableException, MessageNotWriteableException, ResourceAllocationException,
TransactionInProgressException, TransactionRolledBackException), an explicit serialVersionUID has been set which matches
the implicit serialVersionUID of the JMS 1.1 implementation.
For all exceptions that were added in JMS 2.0 (IllegalStateRuntimeException, InvalidClientIDRuntimeException, {{
InvalidDestinationRuntimeException}}, InvalidSelectorRuntimeException, JMSRuntimeException, JMSSecurityRuntimeException,
MessageFormatRuntimeException, MessageNotWriteableRuntimeException, ResourceAllocationRuntimeException,
TransactionInProgressRuntimeException, TransactionRolledBackRuntimeException), an explicit serialVersionUID has been set
which matches the implicit serialVersionUID of the previous JMS 2.0 implementation.
This means that between the JMS 1.1 implementation and this new JMS 2.0 implementation there is full serialization
compatibility (for those exceptions which exist in both versions).
Between the previous JMS 2.0 implementation and this new JMS 2.0 implementation there is serialization compatibility for
the new exceptions added in JMS 2.0.
However between the previous JMS 2.0 implementation and this new JMS 2.0 implementation there is no longer any
serialization compatibility for the older exception classes that were originally defined prior to JMS 2.0.
I am now testing this fix and will let you know when a new version of the JMS 2.0 API jar is released to maven.
Questions and commentsd welcome.
Nigel