This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: serialVersionUID fixes


Am Sonntag, 6. Oktober 2002 12:21 schrieben Sie:
> I noticed that you added serialVersionUID initializations in a few
> files. I'm curious if you've verified that no other serialization
> changes were necessary.  IIRC, if our classes were generating a
> different value from Sun's serialver, that meant there was a class
> divergence that needed to be addressed (or that Sun had modified
> the class and explicitly set a value to indicate some backwards
> compatibility).  Hmm, there was also an issue at one time in how
> the gcj compiler was generating class files that had an unexpected,
> but innocuous, divergence regarding serialVersionUID calculations;
> that was another reason for explicitly setting serialVersionUID.
> It's been a while since I looked at this so bear with my lack of
> certainty ;-).
>
> Perhaps this had already been discussed on the list, I must admit I
> haven't been as diligent in keeping up with the list as I should,
> nor have I had the opportunities I'd hoped to get back to hacking
> on libgcj so I may be a bit out of touch; if so, I apologize.
>
> If there is a need to explicitly set a serialVersionUID in the
> code, it might be helpful to document/comment the issue(s) of why
> it was necessary to do so.  That would be helpful in code review,
> and for folks looking at the code in the future.

From what I read in the mailinglists and the web I know that 
serialVersionUID in SUNs JDK is calced from their API. We need to 
have the some values in serialVersionUID because of serialization 
between libgcj and JDK versions over net. So I used the JDK 1.4.1 
serialver tool to get some (unfortunately not all) serial versions I 
knew that were missing (using some finds/greps) and added them.
The only problem I know of is that I missed some classes that are 
indirectly derived from java.io.Serializable. That has to be done.

In some classes more serialization work needs to be done. I dont 
implemented the missing special serialization methods where missing.
Perhaps thats a job for another one or I do it during compiling of 
libgcj. ;-)

> BTW, thank you for putting the effort into enhancing libgcj;
> especially for all the work you (and others) have put into
> java.net.  That package holds a special place in my heart ;-).  I
> gather that the code has changed significantly from when I first
> wrote those classes, I'm sure for the better. --warrenl

I hope so. I still need a big app testing java.net on its 
functionality and bugfreeness (;-)) that uses the JDK 1.4 features.

I have plans and some code ready for java.nio. I hope this helps.
Another thing is that all has to be merged with classpath where 
appropriate but thats a minor issue.


Michael

-- 
Homepage: http://www.worldforge.org/
GPG-key: http://konqueror.dyndns.org/~mkoch/michael.gpg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]