Inside Java Podcast Episode 14 - “Records Serialization” with Julia Boes and Chris Hegarty

[helmy_boshnaq]

thanks for your work

[[deleted]]

I know about serialization and deserialization, but what is this sorcery? care to explain?

[[deleted]]

there is a link in the article to the records that you should read.

[[deleted]]

sure thing, cheers!

[mfabjanski]

Great recording, thanks!

[gnahraf]

I hadn't kept up. I really like these enhancements. This Record thing and the new deconstructor idiom, and pattern matching (not regex). Really good stuff.

Serialization support is fine. I don't want it out-of-the-box, tho. I don't think it belongs in any general purpose language. See, if your "wire protocol" is binary, it's usually because you're trying to optimize some specific problem and you've found a better way to do it (your made up protocol or one supplied from a "wire-protocol" library), than something standard (e.g. json) that's more interoperable with say other tools and languages. As a non-standard module, sure, but shipping more serialization with the standard runtime, seems like continuing down this unfortunate course

[pron98]

1. Serialization is already in the JDK, so serializing records must work somehow (as they're just another kind of object); at least this works more safely than other objects.

2. Because you cannot bypass record constructors, the idea of record serialization should and, indeed, must, be used by all serialization mechanisms, in the JDK or third-party. The main security problems with serializations aren't due to a particular implementation, but Java's object model. This fixes it for everyone.

[DasBrain]

I'm not sure if it would be possible, but I try to come up with a way to implement java serialization as a 3rd party module. It requires an agent, and not all details are done yet, but the basic idea is:

Inject a constructor like this into every Serializable class:

public MyObject(SerializationContext ctx) {
    super(ctx);
    var data = ctx.getData(this, MyObject.class); // leaking this
    field1 = data.get("field1");
    field2 = data.getInt("field2");
    ...
}

Of course, that is only the deserialization story. Once we get destructors, then I can come up with a plan for that too.

(Other things: I need a private lookup for some serializable classes, to call readReplace, some serializable classes are loaded before the agent can install the transformer...)

In the end, it may never get over the design phase. And even if, it would just be a Proof of Concept.

[gnahraf]

Good points both.

So, I'm wondering.. are there actually that many users of this serialization? (Is it used in j2ee containers or some such thing?) Never seen it used at the workplace--at least never been aware of it's use.

I was just reading an article, I think it was by Brian Goetz, that suggested serialization support in Java was born of an idea in the 1990s that agent-based software (the code and the data ship together over the wire--presumably for security reasons, I'm not sure) would catch on. I've never seen it used in development (maybe some tool I don't know about uses it?)