Restricting serialization to JSON-like objects loses the benefit of being able to "serialize objects". (However, having that separate internal format for data m

Restricting serialization to JSON-like objects loses the benefit of being able to "serialize objects". (However, having that separate internal format for data may well be a better way to go, in general.) The algebraic approach, in this context, is similar to a superclass naming its subclasses (rather than a subclass naming its superclasses as java does). I'm not sure, but I suspect this open-world choice is deliberate, allowing extensibility. Java is very attentive to security considerations elsewhere. It also would be a too-dramatic change for mainstream OO programming languages. A third approach is explicitly closed-world: naming the set of classes permitted for deserialization, as per some other commenters. e.g. JAXB does this by necessity, for binding to XML Schema's algebraic type system.