serialVersionUID

Discussion in 'Java' started by Eitan M, Aug 12, 2007.

  1. Eitan M

    Eitan M Guest

    Hello,

    In some implementations I need to declare something like :
    private static final long serialVersionUID = nnnn;



    can the "nnnn" be by some hot-keys (Eclipse 3.3),

    or should I make a number manually ?



    Thanks :)
    Eitan M, Aug 12, 2007
    #1
    1. Advertising

  2. Eitan M wrote:
    > Hello,
    >
    > In some implementations I need to declare something like :
    > private static final long serialVersionUID = nnnn;
    >
    >
    >
    > can the "nnnn" be by some hot-keys (Eclipse 3.3),
    >
    > or should I make a number manually ?



    It can be anything you like. There's a program that comes with the JDK,
    called "serialver", which will calculate for you the number that the JRE
    would use if you didn't specify serialVersionUID explicitly. This is
    valuable only if you're trying to keep compatibility with previous versions
    of your class. Otherwise, you might as well start with 1, and increment the
    number if you ever change the class incompatibly.
    Mike Schilling, Aug 12, 2007
    #2
    1. Advertising

  3. Eitan M

    Roedy Green Guest

    On Sun, 12 Aug 2007 11:48:27 +0200, "Eitan M"
    <nospam@nospam_please.com> wrote, quoted or indirectly quoted someone
    who said :

    >can the "nnnn" be by some hot-keys (Eclipse 3.3),
    >
    >or should I make a number manually ?


    think of it as a class version number. When you change the layout of
    the class, bump it up by one. See
    http://mindprod.com/jgloss/serialization.html#SERIALVERSIONUID
    for details.

    I find it works best when you manually manage it.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 14, 2007
    #3
  4. Eitan M

    Esmond Pitt Guest

    Roedy Green wrote:
    > think of it as a class version number. When you change the layout of
    > the class, bump it up by one.


    We've discussed this many times before, but I cannot see the point of
    this practice. All that it does is change a *possible* serialization
    exception arising out of a *possible* serialization incompatibility into
    a *definite* serialization exception.

    I personally leave it strictly alone, unless and until I get the
    StreamCorruptedException or whatever exception it is that indicates the
    incompatiblity. *Then* I have a think about what to do about it.
    Esmond Pitt, Aug 14, 2007
    #4
  5. Eitan M

    Roedy Green Guest

    On Tue, 14 Aug 2007 06:35:00 GMT, Esmond Pitt
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >I personally leave it strictly alone, unless and until I get the
    >StreamCorruptedException or whatever exception it is that indicates the
    >incompatiblity. *Then* I have a think about what to do about it.


    The reason is you will get false incompatible streams. The algorithm
    for default serial UIDs includes things that have nothing to do with
    the stream format.

    The danger of the practice is you will fail to change the
    serialVersionUID when you HAVE changed the format.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 14, 2007
    #5
  6. Roedy Green wrote:
    >
    > The reason is you will get false incompatible streams. The algorithm
    > for default serial UIDs includes things that have nothing to do with
    > the stream format.


    Even the version of javac used can change the generated serialVersionUID.

    Tom Hawtin
    Thomas Hawtin, Aug 14, 2007
    #6
  7. Eitan M

    Esmond Pitt Guest

    Roedy Green wrote:
    > The reason is you will get false incompatible streams. The algorithm
    > for default serial UIDs includes things that have nothing to do with
    > the stream format.


    I am talking about your recommendation to bump the serialVersionUID when
    you change the class. You are now apparently talking about not providing
    a serialVersionUID at all. This is not the same thing.

    > The danger of the practice is you will fail to change the
    > serialVersionUID when you HAVE changed the format.


    I don't know what practice you're talking about here, but there is no
    requirement to change the serialVersionUID when you have changed the
    format in a compatible way, and little requirement to do so when you've
    changed it in an incompatible way: all you're doing in that case is
    changing one exception into another.

    The danger of the practice you recommended is that you are quite likely
    to introduce a gratuitous incompatibility.

    Can we stick to the topic please?
    Esmond Pitt, Aug 15, 2007
    #7
  8. Eitan M

    Esmond Pitt Guest

    Thomas Hawtin wrote:

    > Even the version of javac used can change the generated serialVersionUID.


    As the algorithm is very tightly specified in the Serialization
    Specification and the JVM specification I find this rather difficult to
    believe. I'm aware that GNU Java gets it wrong but I've never found any
    evidence to suggest that GNU Java is Java in any useful way.
    Esmond Pitt, Aug 15, 2007
    #8
  9. Esmond Pitt wrote:
    > Thomas Hawtin wrote:
    >
    >> Even the version of javac used can change the generated serialVersionUID.

    >
    > As the algorithm is very tightly specified in the Serialization
    > Specification and the JVM specification I find this rather difficult to
    > believe. I'm aware that GNU Java gets it wrong but I've never found any
    > evidence to suggest that GNU Java is Java in any useful way.


    But the things it depends upon are less well specified. For instance,
    according to section 4.6 of the serialization specification, <clinit> is
    included in the hash. IIRC, if you target 1.4 you need <clinit> for
    ..class constants; if you target 1.5 the ldc instruction takes on that
    roll. There are a number of bugs in the bug parade on the subject.

    Again from section 4.6 of the serialization specification:

    "Note - It is strongly recommended that all serializable classes
    explicitly declare serialVersionUID values, since the default
    serialVersionUID computation is highly sensitive to class details
    that may vary depending on compiler implementations, and can thus
    result in unexpected serialVersionUID conflicts during
    deserialization, causing deserialization to fail."

    http://java.sun.com/javase/6/docs/platform/serialization/spec/class.html

    Tom Hawtin
    Thomas Hawtin, Aug 15, 2007
    #9
  10. Esmond Pitt wrote:
    >
    > I don't know what practice you're talking about here, but there is no
    > requirement to change the serialVersionUID when you have changed the
    > format in a compatible way,


    In fact, there's good reason not t do that.

    > anlittle requirement to do so when
    > you've changed it in an incompatible way: all you're doing in that
    > case is changing one exception into another.


    That is, changing it into an exception whose meaning is obvious rather than
    obscure. I consider that desirable.
    Mike Schilling, Aug 15, 2007
    #10
  11. Thomas Hawtin wrote:
    >
    > But the things it depends upon are less well specified. For instance,
    > according to section 4.6 of the serialization specification, <clinit> is
    > included in the hash. IIRC, if you target 1.4 you need <clinit> for
    > ..class constants; if you target 1.5 the ldc instruction takes on that


    It also depends on synthetic methods and the names of these aren't
    specified at all.
    Mark Thornton, Aug 15, 2007
    #11
  12. "Mark Thornton" <> wrote in message
    news:ifGwi.15159$...
    > Thomas Hawtin wrote:
    >>
    >> But the things it depends upon are less well specified. For instance,
    >> according to section 4.6 of the serialization specification, <clinit> is
    >> included in the hash. IIRC, if you target 1.4 you need <clinit> for
    >> ..class constants; if you target 1.5 the ldc instruction takes on that

    >
    > It also depends on synthetic methods and the names of these aren't
    > specified at all.


    It seems fairly silly to me that it depends on methods at all; why isn't it
    based purely on the names and types of non-transient instance fields, that
    is, the things that are going to be serialized? (And *not* their order, and
    *not* their protection.)
    Mike Schilling, Aug 15, 2007
    #12
  13. Eitan M

    Roedy Green Guest

    On Wed, 15 Aug 2007 01:48:13 GMT, Esmond Pitt
    <> wrote, quoted or indirectly quoted
    someone who said :

    >I don't know what practice you're talking about here, but there is no
    >requirement to change the serialVersionUID when you have changed the
    >format in a compatible way, and little requirement to do so when you've
    >changed it in an incompatible way: all you're doing in that case is
    >changing one exception into another.
    >
    >The danger of the practice you recommended is that you are quite likely
    >to introduce a gratuitous incompatibility.


    I explain fully at
    http://mindprod.com/jgloss/serialization.html#SERIALVERSLIONUID

    I seemed completely obvious to me you would not increment the id for a
    compatible change. That is why you use it, to avoid spurious changes
    when the format did not really change.

    Was anyone else confused?
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 16, 2007
    #13
  14. "Roedy Green" <> wrote in message
    news:...
    > On Wed, 15 Aug 2007 01:48:13 GMT, Esmond Pitt
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >>I don't know what practice you're talking about here, but there is no
    >>requirement to change the serialVersionUID when you have changed the
    >>format in a compatible way, and little requirement to do so when you've
    >>changed it in an incompatible way: all you're doing in that case is
    >>changing one exception into another.
    >>
    >>The danger of the practice you recommended is that you are quite likely
    >>to introduce a gratuitous incompatibility.

    >
    > I explain fully at
    > http://mindprod.com/jgloss/serialization.html#SERIALVERSLIONUID
    >
    > I seemed completely obvious to me you would not increment the id for a
    > compatible change. That is why you use it, to avoid spurious changes
    > when the format did not really change.
    >
    > Was anyone else confused?


    Not I, but I've been dealing with this sort of problem since long before
    Java was still called Oak.
    Mike Schilling, Aug 16, 2007
    #14
  15. Eitan M

    Esmond Pitt Guest

    Roedy Green wrote:
    > Was anyone else confused?


    Well obviously *I* was confused. Could it be this statement:

    > This must change if any characteristics of the pickled Object change.
    Esmond Pitt, Aug 27, 2007
    #15
  16. Eitan M

    Roedy Green Guest

    On Mon, 27 Aug 2007 08:24:06 GMT, Esmond Pitt
    <> wrote, quoted or indirectly quoted
    someone who said :

    >Well obviously *I* was confused. Could it be this statement:
    >
    > > This must change if any characteristics of the pickled Object change.


    I have changed that at your insistence, but I write for the newbie
    not he professor. The newbie will stay out of trouble if they assume
    any change will get them in trouble.

    If they start imagining they can predict when and when a change is
    relevant and when not, they will soon be in hot water.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 31, 2007
    #16
  17. Eitan M

    Esmond Pitt Guest

    Roedy Green wrote:
    > I have changed that at your insistence, but I write for the newbie
    > not he professor.


    I do not understand this. I didn't 'insist' on anything: I only pointed
    out a self-contradiction in your page. What you do about that and who
    you write it for is up to you.

    > The newbie will stay out of trouble if they assume
    > any change will get them in trouble.


    So why not apply that philosophy to the serialVersionUID as well?
    Esmond Pitt, Aug 31, 2007
    #17
  18. Eitan M

    Roedy Green Guest

    On Fri, 31 Aug 2007 07:30:12 GMT, Esmond Pitt
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >I do not understand this. I didn't 'insist' on anything: I only pointed
    >out a self-contradiction in your page. What you do about that and who
    >you write it for is up to you.


    I get several requests for changes every day. Yours about the rudest I
    have received. Of course that does not count the death threats and
    other abuse about the political parts of the site.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Aug 31, 2007
    #18
  19. Eitan M

    Esmond Pitt Guest

    Roedy Green wrote:

    > I get several requests for changes every day. Yours about the rudest I
    > have received.


    You have received no requests from me for changing that part of your
    site. You've received a request for changing another part of your site
    which gratuiously misrepresents of my work. To which you haven't
    responded either publicly or privately.

    > Of course that does not count the death threats and
    > other abuse about the political parts of the site.


    In other words this non-existent communication didn't threaten you with
    death, and wasn't the rudest you have received.

    Your point?
    Esmond Pitt, Sep 2, 2007
    #19
    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. Bent C Dalager

    serialVersionUID best practices

    Bent C Dalager, Oct 1, 2003, in forum: Java
    Replies:
    0
    Views:
    2,974
    Bent C Dalager
    Oct 1, 2003
  2. Denis Labon
    Replies:
    7
    Views:
    13,667
    Tor Iver Wilhelmsen
    Aug 27, 2004
  3. Replies:
    1
    Views:
    756
    Wendy S
    Feb 17, 2005
  4. Henning Winkler

    serialVersionUID verlangt ??

    Henning Winkler, Mar 15, 2005, in forum: Java
    Replies:
    1
    Views:
    2,158
    Henning Winkler
    Mar 15, 2005
  5. Steven

    serialVersionUID and Eclipse

    Steven, Apr 29, 2005, in forum: Java
    Replies:
    1
    Views:
    784
    Peter MacMillan
    Apr 29, 2005
Loading...

Share This Page