On Sat, 2007-08-11 at 09:52 +0200, Mario Ivankovits wrote: > > There are a number of classes that are Serializable but do not declare a > > serialVersionUID value. > > Serializable classes really should, so that later changes which don't > > break serializable compatibility but do change the class checksum can be > > correctly handled as compatible. > > > > Normally, I like starting serialVersionUID at 1 and incrementing from > > there for each incompatible change. > AFAIK there is no way in readObject to get the serialVersionUID of the > stored object, is there a way?
I'm not sure. Why would you want to? > I'd generate the serialVersionUID with any number and use a second local > version which will be written first to the the stream. > That way, we can react in readObject appropriate. > A little bit more complex, but robust about changes. Sorry, I don't understand. You're thinking perhaps that the readObject method could detect the version of data being read in, and set certain fields to default values if the object format is old, else read them from the stream? I guess that is possible but I don't see why Orchestra would need to get that tricky... Can we perhaps start with the default serialVersionUID behaviour, and add this when necessary? BTW, I see only one place where readObject is currently used... There is one apparently tricky case, the ConversationManager. For the other classes, is it ok to add serialVersionUID? For ConversationManager, I see that custom serialization (readObject et al) has currently been implemented, with the comment //we just implement it to make it work with distributed sessions Does this code actually work with distributed sessions? It looks to me like any access to this class on a machine other than the one it was created on will cause exceptions due to things like conversationContexts and conversationManager being null.. > > > In ConversationManager, constant > > CONVERSATION_CONTEXT_PARAM > > is public. > > > > The only user (and the only sensible user) is class > > ConversationRequestParameterProvider > > in the same package. > > > > So could this be made package-scope to avoid exposing this constant in > > the user API? > > > I am not sure about this. I often found myself in bad need to get some > access to a static value like this. On the other hand, I wont veto > against this change. > So if you think its better to have it package-scope, please do so. Well, method getConversationContextId() basically returns the data that is stored under that key, which is the only reason to access that constant. So for the moment I would like to reduce access to it. We can always add it back later, but removing it after publishing a release is a binary compatibility breakage.. Cheers, Simon
