John,
On 25/11/2014 15:48, John D. Ament wrote:
> Nigel,
>
> Seems like something might be a miss here. Are you saying that the
> serialVersionUID must be provided by all implementations?
No, the spec doesn't define whether serialVersionUID should be explicitly set, nor whether instances serialized using
one version of the class must be capable of being deserialized using another. So we don't have a spec violation.
Essentially this is a bug in the JMS 2.0 API jar that the RI has released to Maven Central
http://search.maven.org/#artifactdetails|javax.jms|javax.jms-api|2.0|jar
There is no obligation on anyone to use this. Vendors are free to implement their own versions. However this jar does in
practice have a quasi-official status which is why I am being a bit more formal about fixing it than I would have been
for an internal bug in the RI. (Note that RI bugs can be reported at
https://java.net/jira/browse/MQ)
I don't think there is anything written down anywhere which requires this jar to preserve serialization compatibility,
so I'm not absolutely required to fix it, but I think serializing exceptions and passing them around on the wire is a
reasonable thing to do, and we should provide inter-operability between JMS versions if we can. And this change did
break someone's existing product inter-operability tests.
>
> Perhaps this could be clarified by a TCK test?
Only if we decide to make this a spec requirement.
I'll ask the platform spec leads whether the Java EE compatibility rules impose any particular requirements for
serialization compatibility between versions. (I suspect they'll say that this is up to each spec.)
> 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.
That's not itself invalid. And changing it between versions. as I did, is probably also not invalid, though I think it
is undesirable. However having a serializable object and not setting serialVersionUID is definitely bad coding practice
because it means you might break serialization compatibility accidentally, as I did by removing a "synchronized" keyword.
Nigel
>
> 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