You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <nm...@byteaction.de> on 2006/09/28 17:08:42 UTC
SerialVersionUID and big problems!
Hi Guys,
maybe some of you notice the Bug reported this morning :
http://issues.apache.org/jira/browse/JAMES-639
Im almost sure we are in big trouble now.. Cause if i change the
SerialVersionUID to the same as in 2.2.0 we will break the
userrepositories of the users which start using james with 2.3.0x .
If i use the SerialVersionUID of 2.3.0x we have the same problem with
users of 2.2.0..
Anyone knows if it is possible to write something like a converter ?
Any other ideas ?
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SerialVersionUID and big problems!
Posted by Stefano Bagnara <ap...@bago.org>.
Norman Maurer wrote:
> Im almost sure we are in big trouble now.. Cause if i change the
> SerialVersionUID to the same as in 2.2.0 we will break the
> userrepositories of the users which start using james with 2.3.0x .
> If i use the SerialVersionUID of 2.3.0x we have the same problem with
> users of 2.2.0..
I checked the history for DefaultJamesUser and it doesn't seem to have
changed interface/signatures since 2.2.0 (apart the last initialize
removal). So 2.3.0RCs and 2.2.0 should have the same SerialVersionUIDs
and only trunk after 16 Sep is different: am I wrong?
If so then we should simply add the serialversionUID (the one from
2.2.0) to both 2.3.0 and 2.2.0.
Otherwise, we have to understand why it is not the same: the changelog
does not show changes. Maybe something related to an abstrac class or an
implemented interface changed?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: SerialVersionUID and big problems!
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I just confirmed that James 2.2.0 and James 2.3.0rc3 have the same
> serialversionuid: 6323959976390389529L;
> So we have to add this to trunk
+1
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SerialVersionUID and big problems!
Posted by Stefano Bagnara <ap...@bago.org>.
> Stefano Bagnara schrieb:
>> I checked the history for DefaultJamesUser and it doesn't seem to have
>> changed interface/signatures since 2.2.0 (apart the last initialize
>> removal). So 2.3.0RCs and 2.2.0 should have the same SerialVersionUIDs
>> and only trunk after 16 Sep is different: am I wrong?
>>
>> If so then we should simply add the serialversionUID (the one from
>> 2.2.0) to both 2.3.0 and 2.2.0.
>> [..]
> Thx for checkin this. But i think its not so easy.. From javadocs:
The serialversion depends on sorted methods and something more. Imho it
should not depend on compiler or similar things.
I just confirmed that James 2.2.0 and James 2.3.0rc3 have the same
serialversionuid: 6323959976390389529L;
So we have to add this to trunk where I removed "initialize" method and
"Initializable" interface because it made sense.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: SerialVersionUID and big problems!
Posted by "Noel J. Bergman" <no...@devtech.com>.
> the default *serialVersionUID* computation is highly sensitive to class
> details that may vary depending on compiler implementations, and can
> thus result in unexpected |InvalidClassException|s during
> deserialization. Therefore, to guarantee a consistent *serialVersionUID*
> value across different *java* compiler implementations, a serializable
> class must declare an explicit *serialVersionUID* value.
So declare it for JAMES 2.3 based upon the serialVersionUID defined for the
released binary build of JAMES 2.2.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: SerialVersionUID and big problems!
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Norman Maurer wrote:
>> Im almost sure we are in big trouble now.. Cause if i change the
>> SerialVersionUID to the same as in 2.2.0 we will break the
>> userrepositories of the users which start using james with 2.3.0x .
>> If i use the SerialVersionUID of 2.3.0x we have the same problem with
>> users of 2.2.0..
>
>
> I checked the history for DefaultJamesUser and it doesn't seem to have
> changed interface/signatures since 2.2.0 (apart the last initialize
> removal). So 2.3.0RCs and 2.2.0 should have the same SerialVersionUIDs
> and only trunk after 16 Sep is different: am I wrong?
>
> If so then we should simply add the serialversionUID (the one from
> 2.2.0) to both 2.3.0 and 2.2.0.
>
> Otherwise, we have to understand why it is not the same: the changelog
> does not show changes. Maybe something related to an abstrac class or
> an implemented interface changed?
>
> Stefano
>
Thx for checkin this. But i think its not so easy.. From javadocs:
If a serializable class does not explicitly declare a
*serialVersionUID*, then the serialization runtime will calculate a
default *serialVersionUID* value for that class based on various aspects
of the class, as described in the *Java*(TM) Object Serialization
Specification. However, it is /strongly recommended/ that all
serializable classes explicitly declare *serialVersionUID* values, since
the default *serialVersionUID* computation is highly sensitive to class
details that may vary depending on compiler implementations, and can
thus result in unexpected |InvalidClassException|s during
deserialization. Therefore, to guarantee a consistent *serialVersionUID*
value across different *java* compiler implementations, a serializable
class must declare an explicit *serialVersionUID* value. It is also
strongly advised that explicit *serialVersionUID* declarations use the
|private| modifier where possible, since such declarations apply only to
the immediately declaring class--*serialVersionUID* fields are not
useful as inherited members.
So if i understand write the serialVersionUID is generated from the
class content and the java compiler. So it will be diffrent.
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org