Wenn Serialisierung zur Anwendung kommt, entsteht unmittelbar die Problematik der Version einer Klasse, welche Grundlage fuer ein serialisiertes Objekt war, welches nun deserialisiert werden soll. Solange keine neuen Informationen zu Grunde gelegt werden und nur Methoden veraendert oder hinzugefuegt werden wird dies nicht zu einem Problem fuehren. Die Versionkontrolle wird jedoch in jedem Falle bei Veraenderter Klassendefinition Inkompatibilitaet annehmen und bei dem Versuch des deserialisirens eine java.io.InvalidClassException ausloesen. Wenn man bereit ist die Inkompatiblitaeten selber zu behandeln oder es bewusst machen moechte, laesst sich dies von Hand innerhalb der Methode readObject() umsetzen. Kompatible Anderungen, wie z.B. Hinzufuegen einer Methoden wuerde wie oben beschrieben eine Exception ausloesen. Um die Java Virtual Machine (JVM) nun zu ueberreden, dass die Aenderung gewollt ist, muss man ein Stream Unique Identifier (SUID) zum Einsatz kommen, der die erste kompatible Klasse kennzeichnet. Mit Hilfe des Programmes serialver (Teil des JDKs) lassen sich solche SUID erzeugen, welche dann mit Hilfe einer Konstante (z.b. static final long serialVersionUID = 8984554447612061263L;)in den kompatiblen Quellcode eingesetzt werden. Somit wird die JVM keine Exception mehr ausloesen.