*snip*
Not really what he wants - that's the uncommon case where nothing data changes -
edit: -> this is where i went off the rails (it's not actually what he wants either)

he wants (quite naturally) to avoid breaking the serialization of critical data when something in another part of the graph breaks. Java serialization doesn't really go out of it's way to help with this; but i can tell you that isolation of the unchanging data in a another file/stream is key:
http://www.java-gaming.org/topics/quick-questions-for-mechanims-optimizations/26700/msg/235429/view.html#msg235429Something like that should avoid most problems (except uniqueness == issues, which it may cause because of multiple graphs).
In retrospect serialization should have been position independent somehow if that was possible - as a generic protocol it's utter failure when something as dynamic as code is represented.
If you try to do it as 'it is meant to be used' your major version readObject() conversions (if you don't give up on that) will be byzantine - modify the order of the fields in a holder class? Hello serializable error, goodbye user state.
Now if you're actually talking about changing the (supposedly final) user data; you need to overload readObject and check a version number or something like that you wrote to the stream.
You can maybe try a cascaded switch of versions, with default values on top. I don't know because i am hoping to avoid that layer of hell forever, also, f**k the users.