<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I'd say it's more nuanced than that—Serialization 2.0 can improve over Serializion 1.0 by
<b>allowing users to decide what their formats should be</b>. With Serialization 1.0, it's Java Serialization.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Now, the act of defining (possibly bidirectional) conversions between the in-memory structure of classes and specific output formats typically needs to adhere to some form of specification (hence the word
<b>specific</b>) so it definitely does help to know <b>where such translation needs to occur</b>, which is something Serialization 2.0 can make clear.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
That was my point 🙂</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature" class="elementToProof" style="color: inherit;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
√</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Cay Horstmann <cay.horstmann@gmail.com><br>
<b>Sent:</b> Wednesday, 21 May 2025 13:46<br>
<b>To:</b> Viktor Klang <viktor.klang@oracle.com>; core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>
<b>Subject:</b> [External] : Re: Towards a JSON API for the JDK</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">That's exactly my point. The "specific format" issue doesn't get easier or harder with "serialization 2.0".<br>
<br>
Il 21/05/25 10:56, Viktor Klang ha scritto:<br>
> Hi,<br>
> <br>
> The way to layer a cake like this is as follows:<br>
> <br>
> [ class ] <- describes the general structure of the type (the types, names, and order of the parameter lists)<br>
> [ instance ] <- describes the specific structure of the instance (the values)<br>
> [ structure ] <- converts to/from structure to instance (think constructor / deconstructor pairs)<br>
> [ specific format ] <- converts to/from structure to specific format (think MyCompany JSON Order format version 5)<br>
> [ general format] <- parses / generates the general format (think XML / JSON / CSV / etc)<br>
> [ IO ] <- reads / writes the general format (think file / socket / etc)<br>
> <br>
> <br>
> As for the question how to represent a Timestamp or similar, is answered in the [specific format] layer of this cake. Why? Because the next version of the specification of that layer might change how timestamps should be represented at that layer.<br>
> <br>
> Now, while it is possible to short-circuit some of the layers of the cake by embedding *specific format* decisions at the *class* level, it means that there's now a tight (and somewhat exclusive) link between a *specific format* and *class*, with the implication
that you cannot output the same *instance* as both XML and JSON (as it embeds the decisions of a specific *json schema*. If that was the default, and only, way to go about this, what *specific format* should a library decide to adhere to?<br>
> <br>
> The cake layering at the beginning of this email allows types to be used by many different *specific formats* and even *general formats*, such that you could read something from JSON-over-HTTPS and output it as XML-over-SFTP.<br>
> <br>
> Cheers,<br>
> √<br>
> <br>
> *<br>
> *<br>
> *Viktor Klang*<br>
> Software Architect, Java Platform Group<br>
> Oracle<br>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
> *From:* core-libs-dev <core-libs-dev-retn@openjdk.org> on behalf of Cay Horstmann <cay.horstmann@gmail.com><br>
> *Sent:* Wednesday, 21 May 2025 09:55<br>
> *To:* core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>
> *Subject:* Re: Towards a JSON API for the JDK<br>
> Data binding is indeed complex because real-life JSON is messy. I reviewed some code in which I use Jackson data binding. Here is an example of a sticky issue. I have Content that's either a list of strings or a list of string pairs (don't ask). The JSON
is<br>
> <br>
> { "strings": [..., ..., ... ] }<br>
> <br>
> or<br>
> <br>
> { "pairs": [ { "first", ..., "second", ... }, ..., ... ]<br>
> <br>
> The JavaScript client relies on the fact that exactly one of "strings" and "pairs" exists. No, I can't change the JSON.<br>
> <br>
> I deserialize into a record Content(List<String> strings, List<Pair<String>> pairs) {}. And tweak Jackson to not to serialize entries with null values. It's not pretty, but it is easier than doing tree navigation, since this sits deeply in an otherwise fairly
regular structure.<br>
> <br>
> Could that work with Serialization 2.0? I suppose. Looking at <a href="https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$">
https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$</a> <<a href=""></a>https://urldefense.com/v3/__https://www.youtube.com/watch?v=mIbA2ymCWDs__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkfsczV05g$
>, a marshaller can't dynamically produce either a List<String> or a List<Pair<String>>, so it would offer both in the Marshalled<Content> object, with one of them being null. I would need to tell the wire format generator to write the non-null one. Which
is ok--that's what I do now with Jackson.<br>
> <br>
> Here is another common issue. You have a record TimedPoint(int x, int y, Instant when) {}. How do you want to serialize the Instant? As an ISO 8601 string? Millis since the epoch? Who makes that choice? Slide 29 says "Let the class author be in charge". WHICH
class author? Can java.time.Instant make a universal choice, for all possible wire formats? Surely not. Can TimedPoint? Maybe. Or it is the job of the wire format generator to do that with Marshalled<TimedPoint>?.<br>
> <br>
> So here is my point. If the JDK were to include a JSON data mapper, that data mapper is either rigid or flexible. Designing a flexible data mapper is hard. Serialization 2.0 would not make it any easier.<br>
> <br>
> My hunch is that flexible JSON data mapping is hard to do within the scope of the JDK. Would it follow Jakarta JSON Binding and be tied to that spec? Or strike out on its own? Neither seems attractive.<br>
> <br>
> Ethan and Rémi have presented rigid JSON mappers. They handle nothing but numbers, strings, booleans, maps, lists, records. Is that useful? Surely, for simple programs. For that, there is no reason to wait for Serialization 2.0. If and when that comes, it
would be a natural extension.<br>
> <br>
> Cheers,<br>
> <br>
> Cay<br>
> <br>
> Il 20/05/25 21:46, Paul Sandoz ha scritto:<br>
>> Data binding is a complex feature, even if some examples make it appear simple. Our intention is to explore alignment with the serialization 2.0 effort, when we are ready to so. Hence, I would urge folks to be patience and watch out Brian and Viktor’s Devoxx
2024 talk on the topic.<br>
>> <br>
>> Paul.<br>
>> <br>
>>> On May 20, 2025, at 12:21 PM, Swaranga Sarma <sarma.swaranga@gmail.com> wrote:<br>
>>><br>
>>>> A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0<br>
>>><br>
>>> Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of
the new JEP. Basically a very focused and narrow API:<br>
>>><br>
>>> ```<br>
>>> var jsonStr = "..."<br>
>>> var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants<br>
>>> var serialized = Json.serialize(myRecord)<br>
>>> ```<br>
>>><br>
>>> This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases.<br>
>>><br>
>>><br>
>>> Regards<br>
>>> Swaranga<br>
>> <br>
> <br>
> -- <br>
> <br>
> Cay S. Horstmann | <a href="https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$">
https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$</a> <<a href=""></a>https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$
><br>
> <br>
<br>
-- <br>
<br>
Cay S. Horstmann | <a href="https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$">
https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!LsgfRufAKIgg3ALBXdbz6jTNbzJptqAlG_6z0ni8APQD95TDUOJPleoK0Cy8aIGtoWlLL0BobnUi-Y-nTkc1dP4WTA$</a>
<br>
<br>
</div>
</span></font></div>
</body>
</html>