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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/classpath > -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
