1

If i implementing Serializable on every class of my application so that application can be easily run on Jboss cluster environment.

Now if i implemented Serializable in my classes ,eclipse showing below message

The serializable class does not declare a static final serialVersionUID field of type long

Now it is giving me three options

  1. Add Default Serial version ID
  2. Add generated Serial version ID
  3. Add @SuppressWarings to 'serial'

If i will choose first it will generate like this

  private static final long serialVersionUID = 1L;

If i will choose second it will generate like this

  private static final long serialVersionUID = 1629728947486980072L;

Third we can easily ignore because we have to run the application in cluster environment so we have to add versionID anyhow What is a serialVersionUID and why should I use it?

Now as i told i have to implement serialization each and very class which one is better approach. Approach1 or Appraoch2?

  1. Add Default Serial version ID
  2. Add generated Serial version ID
Community
  • 1
  • 1
Subodh Joshi
  • 12,717
  • 29
  • 108
  • 202
  • 2
    possible duplicate of [What is a serialVersionUID and why should I use it?](http://stackoverflow.com/questions/285793/what-is-a-serialversionuid-and-why-should-i-use-it) – Aestel Aug 17 '15 at 13:09
  • @Aestel this question is not about which u mentioned i am asking which approach is good to generate version ID. – Subodh Joshi Aug 17 '15 at 13:15
  • Look at http://stackoverflow.com/questions/605828/does-it-matter-what-i-choose-for-serialversionuid-when-extending-serializable-cla – Chris K Aug 17 '15 at 13:20
  • Or http://stackoverflow.com/questions/605828/does-it-matter-what-i-choose-for-serialversionuid-when-extending-serializable-cla – Chris K Aug 17 '15 at 13:20
  • possible duplicate of [Why generate long serialVersionUID instead of a simple 1L?](http://stackoverflow.com/questions/888335/why-generate-long-serialversionuid-instead-of-a-simple-1l) – Garry Aug 17 '15 at 13:23
  • flagged as duplicate: http://stackoverflow.com/questions/888335/why-generate-long-serialversionuid-instead-of-a-simple-1l – Garry Aug 17 '15 at 13:24

2 Answers2

2

A serialVersionUID poses a logical burdon: it should be carefully maintained.

Its implicit generation (the compiler hashes method signatures and such), is limited. So no supressing of warnings.

Optimally the version should stay the same as long as possible, and possibly update persisted objects of older class definitions.

At least on a new class definition, the serialVersionUID must be changed.

To make that change more attractive, I use a serialVersionUID in the form of date time yyyyMMddHHmm:

 private static final long serialVersionUID = 201508171605L;

For date time 2015-08-17T16:05.

BTW: a good opportunity to apply underscores:

 private static final long serialVersionUID = 2015_08_17__16_05L;

This makes an overseen version UID more easily identifiable.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • Agree we can use like this `private static final long serialVersionUID = 201508171605L;` so it mean `private static final long serialVersionUID = 1L;` is bed approach ? Because we are choosing Add `Default Serial version ID` it will generate `versionid=1L` now we follow same approach for all the classes what will happen? – Subodh Joshi Aug 17 '15 at 13:44
  • The problem is that seeing 1L or 2L will cause no itch to increase the numer, when the serialized data changes. Chance is, the serialVersionUID is ignored. (OK, there are good teams too.) – Joop Eggen Aug 17 '15 at 14:09
  • Any answer may perhaps be insufficient. The usage of serialization can best be studied in the _internet_, with examples of **version backward compatibility**, the mention that **no constructor is called**, and some more caveats. (Did not find a helpful link after a short try.) – Joop Eggen Aug 17 '15 at 15:11
0

The java.io.Serializable doc says:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException.

So you can think of serialVersionUID as of the 'hash code' of your class. Therefore, second approach is definitely better, as the first is very similar (almost equal) to Add @SuppressWarings to 'serial'.

For more information, visit this blog.

Gawron
  • 85
  • 1
  • 11
  • My Question is that we have to use which approach? for all the classes in project 1- Add Default Serial version ID or 2- Add generated Serial version ID – Subodh Joshi Aug 17 '15 at 13:40