Weijun Wang wrote:
The internal structure of NTLMAuthentication is changed and that's why
I changed the serialVersionUid as well. If unchanged, I guess the old
serialized form can still be accepted by the new class, but all new
field will become null/0. After the change, any such deserialization
should throw a exception immediately.
Of course this means if someone really depends on serialization to
work between different versions of JDK, it would be broken. Is there a
reason why this class, child of AuthenticationInfo, child of
AuthCacheValue, is declared Serializable at the beginning?
It seems to be historical, and may have been used in the earliest days
when the code was part of a browser.
I guess it doesn't matter really then whether the serial uid is changed
or left the same. It's an implementation
class, and not public.
Thanks
Michael.
