[Classpathx-javamail] J2SE 5.0 java.io.Serializable.serialVersionUID Problem

[Conrad T. Pino]

J2SE 5.0 (1.5.x) introduces "java.io.Serializable.serialVersionUID"
http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html

The GNU JavaMail source tree contains 1 inner and 42 outer classes
implementing "java.io.Serializable" and lacking "serialVersionUID";
generating 43 distinct warning messages repeated 1,047 times.

Making the warning go away is trivial; just add the field; however
it's purpose introduces inter-operations issues so I quote Sun,

"The serialization runtime associates with each serializable
class a version number, called a serialVersionUID, which is
used during deserialization to verify that the sender and
receiver of a serialized object have loaded classes for that
object that are compatible with respect to serialization. If
the receiver has loaded a class for the object that has a
different serialVersionUID than that of the corresponding
sender's class, then deserialization will result in an
InvalidClassException."

Since I don't know GNU JavaMail's history well, I'm assume with J2SE
1.4.x serialization operations between GNU and other implementations
is supported or at least possible. Different serialVersionUID values
eliminates any possibility of cross implementation serialization.

I presume Sun's implementation is the reference implementation and
the sampling done so far indicates Sun published serialVersionUID
values reachable from the JavaMail JavaDocs.

The only question then becomes how much testing is appropriate to
ASSURE cross implementation serialization consistent with historic
compatibility assertions.

I propose tracking Sun's serialVersionUID values and withdrawing any
cross implementation compatibility assertions until necessary tests to
verify such assertions are completed, run and passed.

A draft serialVersionUID patch with public Sun values follows next.

Best regards,

Conrad Pino

=====================================================================
The 1 inner class source file follows.
---------------------------------------------------------------------
source/javax/mail/Message.java (inner class RecipientType)
=====================================================================
The 42 outer class source files follow.
---------------------------------------------------------------------
source/gnu/mail/providers/imap/IMAPFlags.java
source/gnu/mail/treeutil/StatusEvent.java
source/javax/mail/event/ConnectionEvent.java
source/javax/mail/event/FolderEvent.java
source/javax/mail/event/MessageChangedEvent.java
source/javax/mail/event/MessageCountEvent.java
source/javax/mail/event/StoreEvent.java
source/javax/mail/event/TransportEvent.java
source/javax/mail/AuthenticationFailedException.java
source/javax/mail/Flags.java
source/javax/mail/FolderClosedException.java
source/javax/mail/FolderNotFoundException.java
source/javax/mail/IllegalWriteException.java
source/javax/mail/MessageRemovedException.java
source/javax/mail/MessagingException.java
source/javax/mail/MethodNotSupportedException.java
source/javax/mail/NoSuchProviderException.java
source/javax/mail/ReadOnlyFolderException.java
source/javax/mail/SendFailedException.java
source/javax/mail/StoreClosedException.java
source/javax/mail/internet/AddressException.java
source/javax/mail/internet/InternetAddress.java
source/javax/mail/internet/MailDateFormat.java
source/javax/mail/internet/NewsAddress.java
source/javax/mail/internet/ParseException.java
source/javax/mail/search/AndTerm.java
source/javax/mail/search/BodyTerm.java
source/javax/mail/search/FlagTerm.java
source/javax/mail/search/FromStringTerm.java
source/javax/mail/search/FromTerm.java
source/javax/mail/search/HeaderTerm.java
source/javax/mail/search/MessageIDTerm.java
source/javax/mail/search/MessageNumberTerm.java
source/javax/mail/search/NotTerm.java
source/javax/mail/search/OrTerm.java
source/javax/mail/search/ReceivedDateTerm.java
source/javax/mail/search/RecipientStringTerm.java
source/javax/mail/search/RecipientTerm.java
source/javax/mail/search/SearchException.java
source/javax/mail/search/SentDateTerm.java
source/javax/mail/search/SizeTerm.java
source/javax/mail/search/SubjectTerm.java
=====================================================================
The 43 distinct warning messages follow.
=====================================================================
The serializable class AddressException does not declare a static final serialVersionUID field of type long
The serializable class AndTerm does not declare a static final serialVersionUID field of type long
The serializable class AuthenticationFailedException does not declare a static final serialVersionUID field of type long
The serializable class BodyTerm does not declare a static final serialVersionUID field of type long
The serializable class ConnectionEvent does not declare a static final serialVersionUID field of type long
The serializable class Flags does not declare a static final serialVersionUID field of type long
The serializable class FlagTerm does not declare a static final serialVersionUID field of type long
The serializable class FolderClosedException does not declare a static final serialVersionUID field of type long
The serializable class FolderEvent does not declare a static final serialVersionUID field of type long
The serializable class FolderNotFoundException does not declare a static final serialVersionUID field of type long
The serializable class FromStringTerm does not declare a static final serialVersionUID field of type long
The serializable class FromTerm does not declare a static final serialVersionUID field of type long
The serializable class HeaderTerm does not declare a static final serialVersionUID field of type long
The serializable class IllegalWriteException does not declare a static final serialVersionUID field of type long
The serializable class IMAPFlags does not declare a static final serialVersionUID field of type long
The serializable class InternetAddress does not declare a static final serialVersionUID field of type long
The serializable class MailDateFormat does not declare a static final serialVersionUID field of type long
The serializable class MessageChangedEvent does not declare a static final serialVersionUID field of type long
The serializable class MessageCountEvent does not declare a static final serialVersionUID field of type long
The serializable class MessageIDTerm does not declare a static final serialVersionUID field of type long
The serializable class MessageNumberTerm does not declare a static final serialVersionUID field of type long
The serializable class MessageRemovedException does not declare a static final serialVersionUID field of type long
The serializable class MessagingException does not declare a static final serialVersionUID field of type long
The serializable class MethodNotSupportedException does not declare a static final serialVersionUID field of type long
The serializable class NewsAddress does not declare a static final serialVersionUID field of type long
The serializable class NoSuchProviderException does not declare a static final serialVersionUID field of type long
The serializable class NotTerm does not declare a static final serialVersionUID field of type long
The serializable class OrTerm does not declare a static final serialVersionUID field of type long
The serializable class ParseException does not declare a static final serialVersionUID field of type long
The serializable class ReadOnlyFolderException does not declare a static final serialVersionUID field of type long
The serializable class ReceivedDateTerm does not declare a static final serialVersionUID field of type long
The serializable class RecipientStringTerm does not declare a static final serialVersionUID field of type long
The serializable class RecipientTerm does not declare a static final serialVersionUID field of type long
The serializable class RecipientType does not declare a static final serialVersionUID field of type long
The serializable class SearchException does not declare a static final serialVersionUID field of type long
The serializable class SendFailedException does not declare a static final serialVersionUID field of type long
The serializable class SentDateTerm does not declare a static final serialVersionUID field of type long
The serializable class SizeTerm does not declare a static final serialVersionUID field of type long
The serializable class StatusEvent does not declare a static final serialVersionUID field of type long
The serializable class StoreClosedException does not declare a static final serialVersionUID field of type long
The serializable class StoreEvent does not declare a static final serialVersionUID field of type long
The serializable class SubjectTerm does not declare a static final serialVersionUID field of type long
The serializable class TransportEvent does not declare a static final serialVersionUID field of type long
=====================================================================

[Conrad T. Pino]

Patch goals:

1. Remove serializable class does not declare a static final
serialVersionUID field of type long warnings, 1,047 in total.

This one is posted on Savannah:
https://savannah.gnu.org/patch/?6290

[Chris Burdess]

Post by Conrad T. Pino
1. Remove serializable class does not declare a static final
serialVersionUID field of type long warnings, 1,047 in total.
https://savannah.gnu.org/patch/?6290

Does this mean that we would have to use the exact serialVersionUID
values that Sun's API does? I'm not clear on this.

[Conrad T. Pino]

Post by Chris Burdess
Does this mean that we would have to use the exact serialVersionUID
values that Sun's API does? I'm not clear on this.

Short answer: maybe, it depends on objectives.
Best answer: we need independent thought cross checking the other.

My understanding and rationale for the proposed patch is here:
http://lists.gnu.org/archive/html/classpathx-javamail/2007-11/msg00011.html
which includes IMO Sun's key statement and link back to the Sun source page
of which the bottom 3 paragraphs apply (the single line is one paragraph).
I made and documented multiple assumptions along the way each of which may
lead to another outcome. Which part or parts are unclear?

[Chris Burdess]

Post by Conrad T. Pino

Post by Chris Burdess
Does this mean that we would have to use the exact serialVersionUID
values that Sun's API does? I'm not clear on this.

Short answer: maybe, it depends on objectives.
Best answer: we need independent thought cross checking the other.
http://lists.gnu.org/archive/html/classpathx-javamail/2007-11/msg00011.html
which includes IMO Sun's key statement and link back to the Sun source page
of which the bottom 3 paragraphs apply (the single line is one paragraph).
I made and documented multiple assumptions along the way each of which may
lead to another outcome. Which part or parts are unclear?

OK, let's proceed on the basis that we are completely ABI-compatible
with Sun's implementation and can therefore use the same
serialVersionUID values. This would allow users to serialise using GNU
and deserialise using Sun, or vice versa.