> There is nothing inherently wrong with Java serialization. I would argue that it's a footgun for the vast majority of developers when a deserialization mecha

> There is nothing inherently wrong with Java serialization. I would argue that it's a footgun for the vast majority of developers when a deserialization mechanism: A) Does something other than restore the exact logical state of the object that was serialized. i.e. can result in arbitrary code execution. This seems hard to entirely exclude from a complex language, but the less likely the language makes it, the more intuitive and safe the language will be for most developers IMO. B) Defaults to deserializing any type of object, as opposed to using an allowlist model. This is such a gaping hole that I'm surprised Oracle hasn't deprecated deserialization without a stream-specific filter, or at least put it behind an --allow-wildly-insecure-deserialization-behaviour-this-is-a-terrible-idea kind of flag. > Is eval() a mistake? Building a language that encouraged developers to exchange messages or store/retrieve data from persistent storage in the form of code that would be passed to eval() would be a mistake.