Re: serialVersionUID problem

[Stuart Ballard]

Serializable is an interface, anyway, not a class. Interfaces can
never be serializable and so it makes absolutely no difference what
serialver returns for them. I'd actually suggest it would be nice if
serialver gave a warning or an error in that case!

Yes, I know that Sun sometimes put serialVersionUID fields on
interfaces. This is an example of Sun not understanding how their own
API works and shouldn't be taken as meaning that those
serialVersionUIDs are doing anything useful.

If you look at the japi results you'll see that there are some
classes, especially quite a lot in Swing, that have incorrect
serialVersionUIDs, but the vast majority are correct. Japi doesn't
compare serialVersionUIDs on interfaces because they're completely
irrelevant.

Stuart.

On 1/19/06, Andrew Haley <address@hidden> wrote:
> hultul writes:
>  > Hi, all~
>  >
>  > I did some tests of java.io.Serializable's serialVersionUID using cp-tools.
>  > All the VM's used in tests were from Debian testing release.
>  >
>  > As a result, kaffe, jamvm, sablevm, and gij showed different results from
>  > Sun's java, where gij in GCC-3.4.3 not in Debian testing release showed 
> same
>  > one with Sun's.
>  >
>  > I guess that there is a problem in java.io.ObjectStreamClass.getClassUID()
>  > or its calling methods in GNU Classpath.
>  >
>  > What do you think about this?
>
> We use the correct algorithm, but serialVersionUIDs aren't guaranteed
> to be the same between libraries, and cannot be.  If you want the
> serialVersionUID of a class of your own to be fixed, you must declare
> the field explicitly.  Some Java compilers (e.g. ecj) emit a warning
> if you fail to do so.
>
> Andrew.
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
>


--
http://sab39.dev.netreach.com/