Generate serialVersionUID in Eclipse for serializable object

Discussion in 'Java' started by Jimmy, Jul 31, 2007.

  1. Jimmy

    Jimmy Guest

    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
     
    Jimmy, Jul 31, 2007
    #1
    1. Advertising

  2. 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.
     
    Kevin Mangold, Jul 31, 2007
    #2
    1. Advertising

  3. Jimmy

    Jimmy Guest

    Thank you for comment. I'll try to keep changing the UID as a habit
    when changing the serialiable source file every time.
     
    Jimmy, Jul 31, 2007
    #3
  4. Jimmy

    Roedy Green Guest

    On Tue, 31 Jul 2007 08:41:03 -0700, Jimmy <>
    wrote, quoted or indirectly quoted someone who said :

    >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
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Jul 31, 2007
    #4
  5. Jimmy

    Twisted Guest

    On Jul 31, 3:38 pm, Jimmy <> wrote:
    > 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.
     
    Twisted, Jul 31, 2007
    #5
  6. Jimmy

    Roedy Green Guest

    >> when changing the serialiable source file every time.
    >It's only necessary to do this when field changes are made


    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.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Jul 31, 2007
    #6
  7. Jimmy

    Lew Guest

    Roedy Green wrote:
    >>> when changing the serialiable source file every time.

    >> It's only necessary to do this when field changes are made

    >
    > 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.

    --
    Lew
     
    Lew, Aug 1, 2007
    #7
  8. Jimmy

    Esmond Pitt Guest

    Jimmy wrote:

    > - 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.
     
    Esmond Pitt, Aug 1, 2007
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven

    serialVersionUID and Eclipse

    Steven, Apr 29, 2005, in forum: Java
    Replies:
    1
    Views:
    798
    Peter MacMillan
    Apr 29, 2005
  2. Markus

    serialVersionUID in Eclipse

    Markus, Jul 20, 2005, in forum: Java
    Replies:
    2
    Views:
    6,114
    Markus
    Jul 21, 2005
  3. Trung Chinh Nguyen
    Replies:
    1
    Views:
    16,035
    Trung Chinh Nguyen
    Jul 27, 2006
  4. Jimmy
    Replies:
    4
    Views:
    660
    Thomas Hawtin
    Aug 8, 2007
  5. Replies:
    8
    Views:
    3,466
Loading...

Share This Page