 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2007serialVersionUID
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 :) > Hello, > [quoted text clipped - 4 lines] > > 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. 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.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > 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. On Tue, 14 Aug 2007 06:35:00 GMT, Esmond Pitt <esmond.pitt@nospam.bigpond.com> 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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > 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 > 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. >> 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 > 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. >> But the things it depends upon are less well specified. For instance, >> according to section 4.6 of the serialization specification, <clinit> is [quoted text clipped - 3 lines] > 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.) > 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? > 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. On Wed, 15 Aug 2007 01:48:13 GMT, Esmond Pitt <esmond.pitt@nospam.bigpond.com> 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 [quoted text clipped - 4 lines] >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? SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > On Wed, 15 Aug 2007 01:48:13 GMT, Esmond Pitt > <esmond.pitt@nospam.bigpond.com> wrote, quoted or indirectly quoted [quoted text clipped - 17 lines] > > Was anyone else confused? Not I, but I've been dealing with this sort of problem since long before Java was still called Oak. > 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. On Mon, 27 Aug 2007 08:24:06 GMT, Esmond Pitt <esmond.pitt@nospam.bigpond.com> 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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > 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? On Fri, 31 Aug 2007 07:30:12 GMT, Esmond Pitt <esmond.pitt@nospam.bigpond.com> 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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > 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? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.