Eric Blake wrote: > > Your summary seemed good to me. Agreed.
> Mark Wielaard wrote: > > > > 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. ... > So I am okay with the proposal to always add a serialVersionUID to all > Classpath files (with libgcj, I'm not as sure that it is necessary, > except for the hassle of maintaining two sources). But I may be a bit > biased, so I look forward to other's views on the matter. Maintaining 2 sources would be too big a hassle IMO; unfortunately, Java doesn't support any kind of conditional preprocessing like #ifdef which would make it easy for Classpath and libgcj to each have it their way. Though I would have prefered only adding serialVersionUID when necessary, I understand the need in Classpath and I'd much prefer avoiding divergence. I very strongly suggest though that people *carefully* check/ensure serialization compatibility when adding serialVersionUID so as not to mask any underlying serialization problems in the class. This might be easier for libgcj folks who can check the computed value which in the majority of cases will be the correct value. Others might have to resort to empirical testing with the JDK to check for compatibility :-( (which is what I had to do when the serialVersionUID's didn't match). --warrenl _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
