Generate serialVersionUID in Eclipse for serializable object

J

Jimmy

When it's a good time to generate this serialVersionUID (say in
Eclipse)?

- In the very beginning when creating this object class? and never
need to change again?
- Every time when changes to getter and setter method in this
class?
- if didn't create it at very first place, generate UID in the
middle of writing this class is ok?

Thanks,
Jimmy
 
K

Kevin Mangold

You can create this whenever you would like it. It is used when you
serialize and deserialize an object. Java needs to make sure the
version of each class is of the same version. The easiest would be to
change it every time you make changes and plan on distributing that
class.
 
J

Jimmy

Thank you for comment. I'll try to keep changing the UID as a habit
when changing the serialiable source file every time.
 
R

Roedy Green

When it's a good time to generate this serialVersionUID (say in
Eclipse)?

- In the very beginning when creating this object class? and never
need to change again?
- Every time when changes to getter and setter method in this
class?
- if didn't create it at very first place, generate UID in the
middle of writing this class is ok?

see http://mindprod.com/jgloss/serialization.html
 
T

Twisted

Thank you for comment. I'll try to keep changing the UID as a habit
when changing the serialiable source file every time.

It's only necessary to do this when field changes are made. In fact,
only when there's some nontransient field foo in the old version and
in the new version it's missing or it's of a more specific type or its
semantics are changed. Generally this means you renamed or deleted a
field, changed it to be of a subclass of whatever it used to be (e.g.
from Collection to List, or List to ArrayList), or changed the
semantics (e.g. double x, y, z used to be interpreted with z being
"up", and now is interpreted with y being "up", or vice-versa).

So when fields recorded basically as name=value pairs are read back in
there'd be nowhere for one to go, or a ClassCastException, or it would
seem to work but something would break further down the line.

Adding a field that can tolerably be left false, zero, or null when
old objects are read back in isn't a problem. If the added field
should have a sensible content, though, and old objects won't work if
this new field is left blank, change the version number.

There's some way of supporting older versions with explicit readObject
methods but you rarely want to.
 
L

Lew

Roedy said:
see http://mindprod.com/jgloss/serialization.html#VERSIONING
for the general rules of thumb about what changes count as changes.
Follow the link there to the Sun site for the lawyer's version.

Also pay close attention to Joshua Bloch's advice about serialization in
/Effective Java/. In summary, he points out that the serialization interface
(as implemented specifically for the class) is another public interface that
must be maintained for the life of the class, and protected from its unique
security and bug risks.

In addition to tricks such as Twisted's implicit recommendation to understand
the "transient" keyword, there are things to do with the readObject(),
writeObject(), readResolve() and other methods.

The trick is to maintain class invariants. You actually don't even really
need to provide a serialVersionUID to get serialization to work, for certain
values of "work". The Java system will make certain default decisions for
anything you don't explicitly implement in your serialization strategy. The
problem is that absent such a strategy they very well could be disastrous
decisions.
 
E

Esmond Pitt

Jimmy said:
- In the very beginning when creating this object class?
Yes.

and never need to change again?

You only *need* to change it when you deliberately want to break
nackwards compatibility with all previous versions and serializations of
the class. Otherwise try to resist the temptation. And read the
Versioning section of the Serialization specification before you even
consider it even then. Then have a look at how to write custom
readObject/writeObject/readResolve/writeReplace methods and define
alternate serializable fields before you consider it further.
Serialization will tell you when it can't understand a stream produced
by an older version, and that's the time to look into these techniques.
- Every time when changes to getter and setter method in this
class?
Nope.

- if didn't create it at very first place, generate UID in the
middle of writing this class is ok?

Just define it before you ever serialize it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top