I don't know much about it ... but would something like Terracotta
use/require/leverage the serialVersionUID for something not so obvious in
normal, singly homed deployments?

I think I understand that it helps confirm or explicitly 'version'
components that might be working together or across, say, JVM boundaries -
but it seems like, if not explicitly provided, a default value is built
automatically and, unless I want an older version to work with a newer
version, I am fine just letting that happen.

In fact, unless I am really abiding by serialVersionUID rules (changing it
explicitly - every time I make a relevant, corresponding change to the
containing class) - I'm not really gaining any functionality that the
runtime can't already do. In fact, unless rigorously maintained, it seems I
could likely end up with two different compiled versions with identical,
explicit serialVersionUIDs - which surely seems worse then leaving it alone?

-Luther


On Sat, Apr 11, 2009 at 10:56 PM, Adriano dos Santos Fernandes <
adrian...@uol.com.br> wrote:

> Brill Pappin wrote:
>
>> Actually i don't think a missing one will cause that to fail unless there
>> are a  lot of incompatible changes.
>>
> Just one incompatible change of class stored in the session and it will not
> be deserialized.
>
>
>> However... even if it does matter, *in no way* should anyone depend on a
>> serialized session to store data.... if your app can't recover from a clean
>> session, you have bigger problems than not adding a serialVersionId.
>>
> Hum? What about stateful pages, which is the Wicket "market"?
>
> If you can control your serial IDs, you have the chance of write custom
> deserializers. That does not means you can't with an absent ID, but AFAIU
> just the inclusion of one field and it will change making the
> deserialization fail.
>
>
>
> Adriano
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to