Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > About generating serialVersionUID using Eclipse 3.1

Reply
Thread Tools

About generating serialVersionUID using Eclipse 3.1

 
 
Sameer
Guest
Posts: n/a
 
      09-04-2005
I am using Eclipse 3.1.
I have created a class which extends Frame and do not implement the
Serializable interface as in the declaration of class.
But still the IDE is giving the warning:
The serializable class 'AnyClass' does not declare a static final
serialVersionUID field of type long.
This is happening with most of the classes.
Using QuickFix to generate serialVersionUID for each class does not
seem to be reasonable.
Is it necessary?
Please clarify.

 
Reply With Quote
 
 
 
 
jan V
Guest
Posts: n/a
 
      09-04-2005
> I have created a class which extends Frame and do not implement the
> Serializable interface as in the declaration of class.
> But still the IDE is giving the warning:
> The serializable class 'AnyClass' does not declare a static final
> serialVersionUID field of type long.
> This is happening with most of the classes.
> Using QuickFix to generate serialVersionUID for each class does not
> seem to be reasonable.


You can just add a line like

// pin the serial version ID down so that we can let this class evolve a
bit without code
// blowing up with incompatible class exceptions.

static final long serialVersionUID = -1L;

... the exact value is not important. The important thing is that
(serialization) compatible classes retain the same value.


 
Reply With Quote
 
 
 
 
Jan Peter Stotz
Guest
Posts: n/a
 
      09-04-2005
Sameer schrieb:

> I am using Eclipse 3.1.
> I have created a class which extends Frame and do not implement the
> Serializable interface as in the declaration of class.
> But still the IDE is giving the warning:
> The serializable class 'AnyClass' does not declare a static final
> serialVersionUID field of type long.
> This is happening with most of the classes.
> Using QuickFix to generate serialVersionUID for each class does not
> seem to be reasonable.
> Is it necessary?


Yes and No. Sun "strongly recommends" to set a static serialVersionUID:

| If a serializable class does not explicitly declare a serialVersionUID,
| then the serialization runtime will calculate a default serialVersionUID
| value for that class based on various aspects of the class, as described
| in the Java(TM) Object Serialization Specification. However, 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
| InvalidClassExceptions during deserialization. Therefore, to guarantee a
| consistent serialVersionUID value across different java compiler
| implementations, a serializable class must declare an explicit
| serialVersionUID value.

Taken from the API documentation of the Interface Serializable:
http://java.sun.com/j2se/1.5.0/docs/...ializable.html

Jan
 
Reply With Quote
 
Roland
Guest
Posts: n/a
 
      09-04-2005
On 4-9-2005 10:18, Sameer wrote:
> I am using Eclipse 3.1.
> I have created a class which extends Frame and do not implement the
> Serializable interface as in the declaration of class.
> But still the IDE is giving the warning:
> The serializable class 'AnyClass' does not declare a static final
> serialVersionUID field of type long.
> This is happening with most of the classes.
> Using QuickFix to generate serialVersionUID for each class does not
> seem to be reasonable.
> Is it necessary?
> Please clarify.
>

It's not necessary as long as you aren't going to serialize your class.

You can configure Eclipse to ignore this problem. For Eclipse 3.1:
Window -> Preferences -> Java -> Compiler -> Errors/Warnings ->
Potential programming problems -> Serializable class without
serialVersionUID -> Ignore.
--
Regards,

Roland de Ruiter
` ___ ___
`/__/ w_/ /__/
/ \ /_/ / \
 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      09-04-2005
Sameer wrote:
> I am using Eclipse 3.1.
> I have created a class which extends Frame and do not implement the
> Serializable interface as in the declaration of class.


You do not declare Serializable, but you inherit it from Frame.

> But still the IDE is giving the warning:
> The serializable class 'AnyClass' does not declare a static final
> serialVersionUID field of type long.
> This is happening with most of the classes.
> Using QuickFix to generate serialVersionUID for each class does not
> seem to be reasonable.
> Is it necessary?


It is a good idea, provided that you are willing to actually *use* the
mechanism by updating the ID whenever you make a change that introduces
a serialization incompatibility. You SHOULD do this, but if you choose
not to do then IMO it is better to not declare a serialVersionUID at all
than to lie about serial version compatibility.

You may also want to consider whether it is really appropriate to
subclass Frame. Unless you are writing a reusable custom GUI component,
it is far more likely that your classes USE or HAVE Frames than that
they ARE Frames. The distinction is perhaps murkier for GUI components
than for many other kinds of classes, but it is no less important. I do
little GUI programming, but in the little I do, I generally avoid
subclassing the standard components.


--
John Bollinger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-05-2005
On 4 Sep 2005 01:18:35 -0700, "Sameer" <(E-Mail Removed)> wrote or
quoted :

>Using QuickFix to generate serialVersionUID for each class does not
>seem to be reasonable.
>Is it necessary?


You want to put in an explicit serialVersionUID with specific value.
Otherwise, every time you sneeze the calculated value will change and
invalidate your serialised datafiles. Manually, you can change the
value only when the structure truly changes. On the other paw, it is
up to you to change it when the layout or names change.

see http://mindprod.com/jgloss/serialization.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
E.J. Pitt
Guest
Posts: n/a
 
      09-05-2005
John C. Bollinger wrote:

> It is a good idea, provided that you are willing to actually *use* the
> mechanism by updating the ID whenever you make a change that introduces
> a serialization incompatibility. You SHOULD do this, but if you choose
> not to do then IMO it is better to not declare a serialVersionUID at all
> than to lie about serial version compatibility.


You should *not* do this. You should leave the serialVersionUID the same
for all versions of a class and let the serialization code figure out
whether versions are serialization-compatible. If you arrive at a
version which is not, you can then provide read/writeObject methods or a
serialPersistentFields member to overcome the differences. If you just
change the serialVersionUID you have broken compatibility permanently
and one day you will rue the day ...
 
Reply With Quote
 
Andrea Desole
Guest
Posts: n/a
 
      09-05-2005


John C. Bollinger wrote:
>
> It is a good idea, provided that you are willing to actually *use* the
> mechanism by updating the ID whenever you make a change that introduces
> a serialization incompatibility. You SHOULD do this, but if you choose
> not to do then IMO it is better to not declare a serialVersionUID at all
> than to lie about serial version compatibility.


good point. How about people forgetting it? I am working with a client
server application. Both client and server should have the same version,
so versioning is, at least at the moment, no issue. Still, considering
that Sun strongly recommends it, I would prefer to use the
serialVersionUID, at least for the class that really are serialized
(that is, the classes that go over the network). But the main reason is
that I am also having problems when testing the client (built with
Eclipse) that connects to a server (built with Ant/javac). I always get
version mismatch. The only way I can do it is first build with Eclipse
and then with Ant, without cleaning.
Still, people are concerned about using serialVersionUID, because people
might forget to update it when necessary.
 
Reply With Quote
 
megagurka
Guest
Posts: n/a
 
      09-05-2005

E.J. Pitt skrev:

> John C. Bollinger wrote:
>
> > It is a good idea, provided that you are willing to actually *use* the
> > mechanism by updating the ID whenever you make a change that introduces
> > a serialization incompatibility. You SHOULD do this, but if you choose
> > not to do then IMO it is better to not declare a serialVersionUID at all
> > than to lie about serial version compatibility.

>
> You should *not* do this. You should leave the serialVersionUID the same
> for all versions of a class and let the serialization code figure out
> whether versions are serialization-compatible. If you arrive at a
> version which is not, you can then provide read/writeObject methods or a
> serialPersistentFields member to overcome the differences. If you just
> change the serialVersionUID you have broken compatibility permanently
> and one day you will rue the day ...


Incorrect. Whenever you change a class in a way that breaks the normal
serialization mechanism, you should increase the serialVersionUID of
the class and implement readObject (no need to implement writeObject)
to be able to read objects of both class versions.

If you never change serialVersionUID it wouldn't be needed at all.

/JN

 
Reply With Quote
 
megagurka
Guest
Posts: n/a
 
      09-05-2005

megagurka skrev:

> E.J. Pitt skrev:
>
> > John C. Bollinger wrote:
> >
> > > It is a good idea, provided that you are willing to actually *use* the
> > > mechanism by updating the ID whenever you make a change that introduces
> > > a serialization incompatibility. You SHOULD do this, but if you choose
> > > not to do then IMO it is better to not declare a serialVersionUID at all
> > > than to lie about serial version compatibility.

> >
> > You should *not* do this. You should leave the serialVersionUID the same
> > for all versions of a class and let the serialization code figure out
> > whether versions are serialization-compatible. If you arrive at a
> > version which is not, you can then provide read/writeObject methods or a
> > serialPersistentFields member to overcome the differences. If you just
> > change the serialVersionUID you have broken compatibility permanently
> > and one day you will rue the day ...

>
> Incorrect. Whenever you change a class in a way that breaks the normal
> serialization mechanism, you should increase the serialVersionUID of
> the class and implement readObject (no need to implement writeObject)
> to be able to read objects of both class versions.
>
> If you never change serialVersionUID it wouldn't be needed at all.


Sorry, seems I'm mistaken :-X. I did some testing and the
serialVersionUID is checked BEFORE readObject in the class is called,
making it impossible to change serialVersionUID if you want to be able
to read old versions of the class. This seems stupid to me, as being
able to read the serialVersionUID from the stream in readObject would
facilitate implementing backward compatible deserialization. Is there a
good reason why the serialVersionUID is checked before readObject is
called?

/JN

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Generate serialVersionUID in Eclipse for serializable object Jimmy Java 7 08-01-2007 11:50 AM
Classes generated by eclipse vs javac have different serialVersionUID tai.thach@gmail.com Java 4 07-28-2006 03:22 PM
Using serialver command line tool to generate serialVersionUID Trung Chinh Nguyen Java 1 07-27-2006 07:43 PM
serialVersionUID in Eclipse Markus Java 2 07-21-2005 04:42 AM
serialVersionUID and Eclipse Steven Java 1 04-29-2005 08:49 PM



Advertisments