@alvoutila,
When you serialize a Serializable object out to disk, it will be written with a special piece of data called the serialVersionUID. It is recommended that you provide this field yourself in the class, but if you don't have one, one will be generated for you. The purpose of the class is to make sure that the object that is saved to disk is still compatible with the class definition loaded in the Java Virtual Machine at run time. In other words, let's say yesterday I had a class:
public class Dog implements Serializable {
String name;
int age;
}
and I wrote a few Dog objects out to disk. But then today I changed the class to
public class Dog implements Serializable {
float weight;
int age;
}
Well, I can't very well read those previous Dog objects off of disk and load them into my currently-running program because the definition of Dog has changed. So yes, most likely, changes you made to your class have made it incompatible with some sort of previously-saved (to disk) instances of the class. It's possible if you are not providing the serialVersionUID field, then the automatically-generated one is being changed by the JVM just because you changed that method's parameters.
This may help some:
http://www.mkyong.com/java-best-practices/understand-the-serialversionuid/
Or the official Java Doc on the subject:
http://docs.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html
"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."