Why We Hate Java Serialization And What We're Doing About It by Brian Goetz & Stuart Marks

[@tohopes]

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.

[@NirajSanghani]

Really insightful. Facing the same problem when processing 20+Million messages per hour

[@khoatranngoc4946]

What is that system?

[@TehBrian]

Khoa Trần Ngọc Discord o-o /s

[@berndeckenfels]

45:20 +1/-1 strategy is not a serious commitment anymore, that does not even touch a LTS release

[@nO_d3N1AL]

Very useful talk on these issues and well overdue. I hope we get another one (albeit likely shorter) on clone() / Cloneable and why that is bad design

[@AndiRadyKurniawan]

I don't like the idea presented in this talk. Why not just use annotation processing that generates the Deserializer and Serializer classes for you?

[@maruseron]

"why not just" in a Brian Goetz talk... precious :-)

[@AndiRadyKurniawan]

​@@maruseron😏

[@ArneBab]

Isn’t the @Serializer pattern just an out-parameter. A Fortran out-parameter?

[@nicohidalgo-toledo1763]

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.

[@shadeblackwolf1508]

I will say, json frameworks can respect rpivacy and use constructors or factory methods if you tell the library where to look

[@mh5259]

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.

[@appsofteng6035]

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.

[@CasparMacRae]

Further application of "destructuring" simplifying/fixing frameworksphere - thank you

Link on the last slide shown at 46:31 : cr.openjdk.java.net/~briangoetz/amber/serialization.html

[@berndeckenfels]

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.

[@witchdodo]

Good talk. But most importantly, I want their computer's stickers on mine.

[@brujua7]

Great, thanks for the talk!

[@mrBrownstoneist]

When first time to try to send object over socket the i faced this. WTH are they thinking..

[@gsit80]

Java should become an ECMA standard. In this way the process of evolving the platform will become more clear.

[@markuskett931]

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.

[@bubbashrimp2655]

What a subtle plug ... :/

[@briangoetz7591]

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.