what problem does the serialization proxy pattern solves that the serialization pattern doesn't solve?

I need to be able to serialize a class into a string, and I know of 2 patterns:

1) (normal) Serialization pattern 2) Proxy Serialization pattern

I've read http://lingpipe-blog.com/2009/08/10/serializing-immu开发者_JAVA技巧table-singletons-serialization-proxy/ (the only website in google that talks about the proxy-serialization pattern) and still cant find the advantage or benefit of using this pattern. Could someone explain what exactly is the proxy serialization pattern, or rather exactly what problem does the proxy-serialization pattern solves that the normal-serialization pattern doesn't solve?

Default serialization:

• Creates multiple instances of classes supposed to be singletons on deserialization
• Supposedly has issues with changed in-the-fly deserialized objects (huh?)

Second point is arguable. Who has changed the data of the bytestream? If it could happen we have a bigger issue than deserialization: security. Signed/encrypted streams would solve the serialization issue too.

First one is real one. Serialize the same singleton a few time, deserialize on the other side, and oops! you have multiple singletons (multitones?). That problem though is IMHO easier solved by making a singleton out of Enum, then JVM will enforce the single instance itself.

UPDATE

As was pointed out by Steve B, the blog poster perhaps misunderstood/misrepresented what did he read. Instead of "serialize, tweak bytes, then deserialize" one should read "serialize, deploy new version of the class, deserialize". Yes, this is known problem, and Externalizable interface allows one to solve it neatly by taking a full control over the class serialization, so even the later version of the class can deserialize own data from a stream created by a previous versions (if it possible at all).