Baking serialization into the programming language presumes that there is one canonical way to serialize the data of each object. But there may be multiple different ways to externally represent a given object - different forms to persist to a file on disk, to send to this system, to send to that system. It's still too magical.
Nice presentation. Thank you. In my experience data objects that represent some more complex problem domain usually have direct or indirect cyclic references, typically parent - children, whole - parts etc. That's why both JPA and JAXB offer some solutions such as bidirectional references, @XmlID, @XmlIDREF, public void afterUnmarshal(Unmarshaller unmarshaller, Object parent) etc.
To follow up on the point made by Andy earlier, it feels like this work complects the success of updating Serialization to Pattern Matching unnecessarily. I've done that type of "use improvement B we really want to justify the necessity of implementing feature A" reasoning in my work, so I understand the impetus... But it really feels like this can be accomplished using existant mechanisms. The big insight/evolution here is to use annotations instead of implementing an interface. For instance, consider the existence of a @Serializable(serializationStrategy=SerializationStrategyInstance.class) public interface SerializationStrategy { ObjectOutputStream serialize(T instance) T deserialize(ObjectInputStream stream) } Then you can use a ServiceLoader to populate the available SerializationStrategy in the classpath and implement a default dispatching mechanism fairly easily. At least, in theory. I haven't tried implementing it. But the approach seems straightforward. Sure, Pattern Matching might make things syntactically nicer, but I'm not sold that it's a blocker or even a huge enabler here.
Important talk, but no mentioning of ysoserial and Chris Frohoff and the other researchers in that area? github.com/frohoff/ysoserial (Learning from that also tells us that running code while deserialisation might be risky, ask your local collection). Talk also does not mention the new filter hooks on ObjectInputStream either.
I started coding when I was 49, which was 3 and a half years ago... I had to figure out a vulnerability fix related to Serialization, so I came here, but I'm pretty sure I will retire before I understand WTF these guys are talking about.. I know ignorance doesn't sell in this world, but damn. I think I'll stick with the friendly confines of React and the relative child's play of hooks.
A free solution from the community has already solved most of these problems. MicroStream is a fundamentally new written serialization that enables you to store any Java object graph on disk and load it back to the memory partially very easily, which means you can even update your object graph in the memory. It was created to enable Java to store any kind for any kind of use-cases and to replace heavy-weight DMBS, especially for microservices use cases. It provides high-security deserialization and object graph communication, and it's free.
I think maybe you missed the part where "any serialization framework that recreates objects is subject to the same exploits". There are zillions of free alternate serialization frameworks; that's not news. But unless you interact with the data entirely outside of the object model (e.g., through a DOM-like model of maps and lists), you're back in the same problems.
