Therefore, deserializing the set causes the hashCode method to be invoked over 2100 times. Other than the fact that the deserialization is taking forever, the deserializer has no indication that anything is amiss. Few objects are produced, and the stack depth is bounded. So what can you do defend against these problems? You open yourself up to attack whenever you deserialize a byte stream that you don’t trust. The best way to avoid serialization exploits is never to deserialize anything. In the words of the computer named Joshua in the 1983 movie WarGames, “the only winning move is not to
...more
So it's quite clear that Java made a bad decision when it chose to use this method of serialization (and perhaps a bad decision to even have Serialiizable all together). We've also heard about a handful of other bad decisions throughout this book (poor method names/overloadings, unnecessary synchronization, etc.).
Is Java ever willing to create a version that at least begins to trim off some of this legacy? How about deprecating some of those for at least one major version, and removing the, a major version or two later?
The cost will be high, but I'm sensing the cost will be higher if it does nothing; it will slowly fade away as alternatives with most of the benefits and few of its drawbacks pop up and gain traction (Kotlin replacing Java, Swift replacing ObjC).
