Hi, There was a small discussion on [EMAIL PROTECTED] (between Warren Levy, Tom Tromey, Michael Koch, Eric Blake and myself) when some of the newly added serialVersionUID fixes made by Michael were merged into libgcj. Since I assume not everybody reads that list I give the summary here (I hope one of the above people will correct me when I make a wrong conclusion).
The specification for computing a Stream Unique Identifier (serialVersionUID) when it is not declared in a class is given here: http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/class.doc6.html This algorithm is implemented in java.io.ObjectStreamClass and for a Serializable class you can get the serialVersionUID by calling: ObjectStreamClass.lookup(Class).getSerialVersionUID() Warren Levy has made sure that our implementation gets all the corner cases right (or at least does the same as the Sun version) and that gcj generates class files that contain as much as possible the same method names as the Sun javac compiler does. So the rule for libgcj was: If the serialVersionUID is different from that calculated by the SUN JDK, then figure out _why_ it's different and fix either the compiler, or the class method names, or the ObjectStreamClass implementation and only if all that fails add a serialVersionUID and make sure to add a comment why it is necessary. But when we recently discussed the issue on this list (and as pointed out again by Eric Blake in the above discussion) the synthetic method names generated by different java bytecode compilers for e.g. inner classes access to private variables of their outer class or to implement the SomeClass.class construct are note the same. (Eric gives a nice example in the following email: http://gcc.gnu.org/ml/java-patches/2002-q4/msg00036.html.) And we currently use either jikes or GNU gcj to compile GNU Classpath which don't generate the same accessor method names. What I don't understand is why it is so hard to specify the actual accessor methods. Does anybody know why they were never clearly specified? If both Tom Tromey and Eric Blake say that although theoretical possible, it is too difficult for us to ensure compatibility in the free compilers with the proprietary Sun javac naming scheme and other synthetic stuff I think that are current policy (always add serialVersionUID if the class is Serializable) is a good one. What do others think? Should we try to reverse engineer the naming scheme? Or do we keep the current policy? Or we could even ignore being serializable compatible with the Sun JDK till this is clearly specified. Cheers, Mark _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath