> 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.

If the use of `eval()` isn't plainly obvious (even to someone who's inexperienced in Java), then yes, it's a mistake.

I shouldn't have to read the docs to find out that a seemingly innocent operation is in fact extremely dangerous.

Eval() in js is not a security hole (at least not in the RCE sense). Eval of arbitrary data from an untrusted source in an environment where “arbitrary execution in the host environment means arbitrary code execution with user privileges” is.

That said arbitrary code execution as part of object deserialization has been a known severe attack vector since the 90s, and the fact that Java still allows it by default without massive restrictions is fairly appalling.