serialVersionUID needs to be updated everytime I make changes in my JSF project

Question

It's pretty annoying, everytime I make changes in my managedbean, I need to generate a new serial version id, in order to make changes in my project, and it is pretty inconvenient, I thought there was a problem with my server so I restarted my apache several times, and now I discovered the the serialversion id should be deleted then generated over and over and over again, I this how JSF works?

EDIT: Now it's getting crappy everytime I make changes in my code, I will delete the serialversion id, generate a new one, and generate again, else if wont apply the changes, very crappy

EDIT: Now my project is running correctly, simple answer to my problem is that, I didn't generated the serialVersionID and always clean the project. Sometimes the IDE doesn't detect the changes in other classes so you need to clean and restart the server.

Answer 1

Well, the purpose of the serialVersionUID is to deal with changes in your class that will (or could) lead to problems when the code of the classes that serialize and deserialize an object is different. There are a few approaches:

1. Don't use a serialVersionUID field. The JVM will generate the UIDs on the fly based on the version of the class that is being serialized and deserialized. If the UIDs don't match you will get an exception.

2. Use a serialVersionUID field and don't update it. This is a bit dangerous. If you make an incompatible change, you will probably get an exception because the representation descriptors in the serialized class don't match what the deserializer expects. But you might not, and that is the real problem. (The transmitted data may have the wrong meaning!)

   This is safe if you know for sure that the versions of the class at serialization and deserialization time will always be the same. But scenarios / use-cases where you can guarantee that are pretty unusual.

3. Use a serialVersionUID field and regenerate it only when you make a class change that you assess as likely to cause version compatibility issues. The risk is that you get it wrong, and don't regenerate when you need to. This will lead to the same problems as 2. above.

4. Use a serialVersionUID field and regenerate it whenever you change the class.

5. Don't use object serialization. Use XML or JSON instead. (With schemas... if you want a degree of interface compatibility checking.)

---

But the bottom line is that you can't actually avoid the problem of compatibility of representations passed between services in a distributed system.