Nigel,
Seems like something might be a miss here. Are you saying that the
serialVersionUID must be provided by all implementations? Take for
instance the apache implementation.
https://github.com/apache/geronimo-specs/blob/1_0/geronimo-spec-jms/src/java/javax/jms/JMSException.java
This version does not include a serialVersionUID attribute.
Perhaps this could be clarified by a TCK test?
John
On Tue, Nov 25, 2014 at 10:34 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> 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