Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

serialVersionUID

 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you guys declare

in all your serializable classes ?

i think i�m well aware of what it does to the serialization process, so i�d prefer not to declare �em.
it just popped into my mind because some "static code analyzers" raise the issue.

what is your point of view ?
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why wouldn't you want to declare it? I thought it was accepted "good practice" to create a SerialVersionUID (see Effective Java book, and Java RMI recommends it too).
 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
*g* as you mention "Java RMI"... it says:

"The downside to using serialVersionUID is that, if a significant change is made (for example, if a field is added to the class definition), the suid will not reflect this difference. This means that the deserialization code might not detect an incompatible version of a class."

and furtheron suggests to implement readObject & friends and writing a version "manually".

All this in order to gain performance:

"Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don't set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value."

As performance is not the issue here, i tend to walk the safe path and do not provide a serialVersionUID.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That downside will only surface when you fail to change the serialversionUID when changing the serialisable interface of the class, which means it will only happen if you don't do what you're supposed to do
 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen Wenting:
That downside will only surface when you fail to change the serialversionUID when changing the serialisable interface of the class, which means it will only happen if you don't do what you're supposed to do


or if some junior programmer is not

maintainability for a junior programmer is a requirement in my assignment.
so i suppose introducing a risk by adding a (maybe not that intuitive, from a junior�s POV) chance to make a mistake for the sake of performance is not the way to go here, right ?
 
Lara McCarver
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Effective Java, on p. 223, the author says,

Regardless of what serialized form you choose, declare an explicit serial version UID in ever serializable class you write. This eliminates the serial version UID as a potential source of incompatibility (Item 54).


He also mentions the performance issue, but the way it is written, this incompatibility issue is presented as the biggest reason to declare a UID.

Item 54, on p. 214 discusses this incompatibility concern. The automatically generated version is affected by its name and the interfaces it implements, as well as the exact signature of every public and protected method and member variable. If you change any of these things in any way, even if it is just a little refactoring which required you to add a protected method, the serial version UID will change. Once the serial version UID changes, compatibility with clients is broken.

I think what he means is that you would have to recompile your client app in order to pick up the new version UID.

Applying this to the SCJD exam, we have a single jar file which implements both the client and server, so it would seem like there is no danger... when you get a new server, you will also get a new client. But in a real world situation, it is extremely valuable to be able to modify the server code and the client code independently of each other.

My worry would be that if you leave out the explicit declaration of a serial version UID, you are intentionally using a model with bad side effects, and why would you do this when it is so easy to declare.
[ May 10, 2005: Message edited by: Lara McCarver ]
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The other option would be to implement Externalizable.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
or if some junior programmer is not

maintainability for a junior programmer is a requirement in my assignment.
so i suppose introducing a risk by adding a (maybe not that intuitive, from a junior�s POV) chance to make a mistake for the sake of performance is not the way to go here, right ?


I used suid in my assignment and did not get any points marked off for it I had never even considered not using it. IMHO it is bad practice not to. But if you choose not to, I doubt you will lose any points. Just put your justification not to do so in your choices.txt.

If you want to play it safe, use a suid - it worked for me!
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello guys,

I was wondering how you calculate the UID? I am awaire it is a hash of the class, but how exactly do u calculate it?

Thanx for your help.

James.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
doesn't really matter, it's just a number used to identify the class and version
You could just use a serial number for the class and a timestamp for the version for example and do something to combine the two.
 
Kim Lauwers
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
May I let Eclipse generate the serial ID or do I really have to use the date?

If not:
I read that you must use the current time. So would this be good:
private static final long serialVersionUID = new Date().getTime();

Thanks
Kim
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm facing a similiar issue and I'm using eclipse to generate this for me. Is that a good practice to allow eclipse to generate one for all my Serializable classes?
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kim Lauwers:
May I let Eclipse generate the serial ID or do I really have to use the date?

Yes you may. You can also set it to 1L, it really doesn't matter.

Originally posted by Kim Lauwers:

If not:
I read that you must use the current time. So would this be good:
private static final long serialVersionUID = new Date().getTime();

No way! This means your classes will never be compatible if they are on separate machines. What good would that be?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic