I think what has been proposed so far is powerful enough to perform that
task *if* there is an intermediate object in the mix.
if (
// Assuming a dual pattern for JsonString.of and the SAP
// strategy outlined in the doc
json instanceof index(0, JsonString::of).decode(var firstName)
)
I think you missed a 2.5 which is to use the information in DOM objects to
perform useful work.
On Wed, May 21, 2025, 1:04 PM Archie Cobbs wrote:
> On Wed, May 21, 2025 at 11:30 AM Paul Sandoz
> wrote:
>
>> I consider this a “known unknown” (in the words of Mr. Rumsfeld). We
>> would need to ex
On 21/05/2025 18:06, Paul Sandoz wrote:
It was a design choice to be consistent with each json value having an
X, accepting X in on construction and producing X out (notionally) on
deconstruction, which leans into pattern matching. Definitely pros/cons
to that e.g., we could instead make JonObje
Thank you Archie, nicely expressed.
The discussions in this thread will help us write a crisper set of
goals/non-goals and a clearer motivation for the to-be-written JEP.
Paul.
On May 21, 2025, at 10:03 AM, Archie Cobbs wrote:
On Wed, May 21, 2025 at 11:30 AM Paul Sandoz
mailto:paul.san...@o
It was a design choice to be consistent with each json value having an X,
accepting X in on construction and producing X out (notionally) on
deconstruction, which leans into pattern matching. Definitely pros/cons to that
e.g., we could instead make JonObject implement Map, or do as you suggest [
On Wed, May 21, 2025 at 11:30 AM Paul Sandoz wrote:
> I consider this a “known unknown” (in the words of Mr. Rumsfeld). We would
> need to explore this area throughly, which includes the interconnection
> with Serialization 2.0, before we really know what we can and should do in
> the near and lo
I consider this a “known unknown” (in the words of Mr. Rumsfeld). We would need
to explore this area throughly, which includes the interconnection with
Serialization 2.0, before we really know what we can and should do in the near
and long term. That’s a significant effort, and I would like to s
th you our thoughts and plans towards a JSON API for
the JDK.
Please see the document below.
-
We have had the pleasure of using a clone of this API in some experiments we
are conducting with
ONNX and code reflection [1]. Using the API we were able to quickly write code
to ingest and convert
a JSO
In the my world - which I am again very interested in revisiting once there
is a version of patterns I can touch - you may approach that problem in the
following way:
sealed interface Content extends JsonEncodable {
static Content fromJson(Json json) {
return switch (json) {
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: Cay Horstmann
Sent: Wednesday, 21 May 2025 13:46
To: Viktor Klang ; core-libs-dev@openjdk.org
Subject: [External] : Re: Towards a JSON API for the JDK
That's exactly my point. The "specific
m:* core-libs-dev on behalf of Cay Horstmann
*Sent:* Wednesday, 21 May 2025 09:55
*To:* core-libs-dev@openjdk.org
*Subject:* Re: Towards a JSON API for the JDK
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 examp
a Platform Group
Oracle
From: core-libs-dev on behalf of Cay Horstmann
Sent: Wednesday, 21 May 2025 09:55
To: core-libs-dev@openjdk.org
Subject: Re: Towards a JSON API for the JDK
Data binding is indeed complex because real-life JSON is messy. I reviewed some
code in which I use Jackson d
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
{ "strings": [..., ..., ... ] }
or
statements can
implement .setJson and .getJson for DBMS supporting Json type (like
Postgres).
David.
-- Forwarded message -
De: Paul Sandoz
Date: mar, 20 de may de 2025, 14:46
Subject: Re: Towards a JSON API for the JDK
To: Swaranga Sarma
Cc: Remi Forax , Brian Goetz ,
core-libs-dev
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.
Paul.
> On
> It’s a not a goal to solve the dependency problem (a very hard problem!)
even in a narrow sense.
That was only an example where a data-binding API would be useful - it
wasn't a meant to be the only use-case or even a suggestion that it should
be solved in the general case.
> A potential advanta
JEP 198 will likely be withdrawn and a new JEP will be drafted aligned with the
document sent in this email thread.
It’s a not a goal to solve the dependency problem (a very hard problem!) even
in a narrow sense.
A potential advantage that we (the OpenJDK community) can more easily do is
devis
* Brian Goetz:
> But then we discovered that JSON5 also sneaks in some semantics, by
> also supporting the exotic numeric values (NaN, infinities, signed
> zero), which now has consequences for "what is a number", the numeric
> representation, the API for unpacking numeric values, etc. (Having
>
I think I see what you mean, although to me the general characterization as
construction/deconstruction is too narrow - there are a zillion ways to pack-in
and pack-out the tree, some partial, and some lossy etc. The canonical
pack-in/out is arguably parsing and writing from and to JSON document
uot; , "core-libs-dev" <
> core-libs-dev@openjdk.org>
> *Sent: *Monday, May 19, 2025 11:18:26 PM
> *Subject: *Re: Towards a JSON API for the JDK
>
> Those extending the non-sealed subtypes of JsonValue must conform to the
> requirements that are specified. The curren
What I mean by central in this context isn't that it's at the core of
things and features are built on top of it - as you note it is a valid
transformation of the hierarchy.
What I mean is that absent other construction/deconstruction apis it is the
most convenient avenue for those tasks. So code
> From: "Paul Sandoz"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "core-libs-dev"
>
> Sent: Monday, May 19, 2025 11:18:26 PM
> Subject: Re: Towards a JSON API for the JDK
> Those extending the non-sealed subtypes of JsonValue must
specified for
implementations of List.
Paul.
On May 19, 2025, at 1:56 PM, fo...@univ-mlv.fr wrote:
From: "Paul Sandoz"
To: "Remi Forax"
Cc: "Brian Goetz" , "core-libs-dev"
Sent: Monday, May 19, 2025 10:02:50 PM
Subject:
Paul,
thank you for picking up the topic JSON. I do like the simplicity of
your proposal, OTOH I have concerns:
* Will it it be sustaining?
We added a XML API when XML was "the" big thing, and now it is not a big
thing anymore and we can't get rid of the XML API without breaking
things. So
> From: "Paul Sandoz"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "core-libs-dev"
>
> Sent: Monday, May 19, 2025 10:02:50 PM
> Subject: Re: Towards a JSON API for the JDK
>> On May 19, 2025, at 8:16 AM, Remi Forax wrote:
&g
Hi Cay,
It would be really helpful to share some more detailed use-cases on
editing/modification that you may reasonably expect users to perform.
I hope we might be able to devise a transformation API, hopefully layered on
top of the public API and possibly with structural sharing for unmodifie
The approach to the design of this API leans heavily on ongoing and future
language and library features. This is why the API is so small as we don’t want
conflicts with what we may do in the future. In the document we briefly mention
data binding but don’t provide further context:
Advanced fea
On May 19, 2025, at 8:16 AM, Remi Forax wrote:
Okay,
i've taken a look to the design and this is not pretty.
That seems an exaggerated statement to me. It's a trade-off, a compromise,
allowing others to implement their own parsers, perhaps from non-textual
representations. So of course we c
On May 17, 2025, at 4:37 AM, Ethan McCue wrote:
I think it's worth noting that the way you used the prospective API in your
ONNX code is not representative of how the API would generally be used in a
jdk-only scenario. Custom making a general transformation from JsonValue ->
Record is outsid
>
> This is part of why fromUntyped/toUntyped is uncomfortable - it's choosing
> one particular encoding of JSON and making it central to the API. Is that
> really the most important encoding?
>
It's one opinionated kind, a simple bi-directional mapping
(embedding-projection pair) based on
Hi,
On 5/17/25 10:55 PM, Cay Horstmann wrote:
PS. Trying to create and show the youthful John gives me grief right now:
Json.fromUntyped(Map.of("name", "John", "age", 30)).toString()
| Exception java.lang.NullPointerException: Cannot read the array
length because "value" is null
| at
envisioned core API.
Thanks
Johannes
# Towards a JSON API for the JDK
One of the most common requests for the JDK is an API for parsing and generating
JSON. While JSON originated as a text-based serialization format for JSON
objects ("JSON" stands for "JavaScript Object Notation&qu
s,
Rémi
> From: "Remi Forax"
> To: "Brian Goetz"
> Cc: "Paul Sandoz" , "core-libs-dev"
>
> Sent: Friday, May 16, 2025 8:42:47 PM
> Subject: Re: Towards a JSON API for the JDK
>> From: "Brian Goetz"
>> To: &q
- Original Message -
> From: "cay horstmann"
> To: "Remi Forax"
> Cc: "core-libs-dev"
> Sent: Monday, May 19, 2025 4:12:55 PM
> Subject: Re: Towards a JSON API for the JDK
> Il 19/05/25 10:13, Remi Forax ha scritto:
>>> If only
Il 19/05/25 10:13, Remi Forax ha scritto:
If only there was some deconstruction magic that approximates the JavaScript
code
const doc = { name: "John", age: 30 }
const { name, age } = doc
We already have that, it's called a record :)
Basically, you are advocating for a mapping JsonObject <-->
- Original Message -
> From: "cay horstmann"
> To: "core-libs-dev"
> Sent: Sunday, May 18, 2025 7:55:12 AM
> Subject: Re: Towards a JSON API for the JDK
Hello Cay,
> +1 for having a JSON battery included with the JDK. And for "Our primary goal
g.rangeCheck (String.java:307)
|at String. (String.java:303)
|at JsonNumberImpl.toString (JsonNumberImpl.java:105)
|at JsonObjectImpl.toString (JsonObjectImpl.java:56)
|at (#23:1)
The JsonNumberImpl.toString method needs to handle the case that it was
constructed from
e interested in an
experience report of using it straight up.
On Thu, May 15, 2025 at 10:31 PM Paul Sandoz wrote:
> Hi,
>
> We would like to share with you our thoughts and plans towards a JSON API
> for the JDK.
> Please see the document below.
>
> -
>
> We have had the
tions.
>
> --
> 发件人：forax
> 发送时间：2025年5月17日(周六) 02:43
> 收件人：Brian Goetz
> 抄 送：Paul Sandoz; "core-libs-dev"<
> core-libs-dev@openjdk.org>
> 主 题：Re: Towards a JSON API for the JDK
>
>
>
&g
> instead of a record ?
>>
>> I understand why Json.parse() only works on String and char[] but the API
>> make it too easy to have many performance issues.
>> I think you need versions using a Reader and a Path.
>> Bonus point, if there is a method walk() that also r
发件人：forax
发送时间：2025年5月17日(周六) 02:43
收件人：Brian Goetz
抄 送：Paul Sandoz;
"core-libs-dev"
主 题：Re: Towards a JSON API for the JDK
From: "Brian Goetz"
To: "Remi Forax"
Cc: "Paul Sandoz" , "core-libs-dev"
Sent: Friday, May 16, 2025 7:46:09 PM
Subject:
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Paul Sandoz" , "core-libs-dev"
>
> Sent: Friday, May 16, 2025 7:46:09 PM
> Subject: Re: Towards a JSON API for the JDK
> If you read the implementation, you'll see that significan
- Original Message -
> From: "naoto sato"
> To: "Remi Forax" , "Paul Sandoz"
> Cc: "core-libs-dev"
> Sent: Friday, May 16, 2025 6:35:50 PM
> Subject: Re: Towards a JSON API for the JDK
> Hi Rémi,
>
> On 5/15/25 2:27 PM
ginal Message -
From: "Brian Goetz"
To: "Remi Forax", "Paul Sandoz"
Cc: "core-libs-dev"
Sent: Friday, May 16, 2025 2:53:18 PM
Subject: Re: Towards a JSON API for the JDK
On 5/15/2025 5:27 PM, Remi Forax wrote:
It's not clear to me why JsonArray
Thanks for the sneak peek.
I'd suggest adding a security section to the JEP, when the time comes. Most
input to this JSON parsing API will probably be untrusted, and this is an
area where "last mover advantage" can be helpful. As a user, the
progression I've seen in other JSON parsers was a first
Since the parser is specified to be lazy, the backing store needs to be
immutable.
On 2025-05-16 18:52, Markus KARG wrote:
When instead allowing the
general interface CharSequence, *any* kind of text source can be parsed,
for example, an off-heap located direct CharBuffer, without the need to
(like JSON.stringify in JS).
regards,
Rémi
- Original Message -
From: "Paul Sandoz"
To: "core-libs-dev"
Sent: Thursday, May 15, 2025 10:30:42 PM
Subject: Towards a JSON API for the JDK
Hi,
We would like to share with you our thoughts and plans towards a JSON API for
the JDK
2025 10:30:42 PM
Subject: Towards a JSON API for the JDK
Hi,
We would like to share with you our thoughts and plans towards a JSON API for
the JDK.
Please see the document below.
-
We have had the pleasure of using a clone of this API in some experiments we are
conducting with
ONNX and code reflect
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax" , "Paul Sandoz"
> Cc: "core-libs-dev"
> Sent: Friday, May 16, 2025 2:53:18 PM
> Subject: Re: Towards a JSON API for the JDK
> On 5/15/2025 5:27 PM, Remi Forax wrote:
reasonable alternative
>>> implementations - as far as I can imagine, maybe i'm wrong - so
>>> maybe those can just be final classes?
>>> * If you seal up the whole hierarchy then its pretty trivial to make
>>> it serializable
>>> (https://github.com/bowbahdoe/
a is an issue for beginners.
>>
>> It's not clear to me why JsonArray (for example) has to be an interface
>> instead of a record ?
>>
>> I understand why Json.parse() only works on String and char[] but the API
>> make it too easy to have many performance issues.
&
rom: "Paul Sandoz"
> To: "core-libs-dev"
> Sent: Thursday, May 15, 2025 10:30:42 PM
> Subject: Towards a JSON API for the JDK
> Hi,
>
> We would like to share with you our thoughts and plans towards
a JSON API for
> the JD
populated lazily.
>
> Minor point: Json.toDisplayString() should takes a second
> parameters indicating the number of spaces used for the
> indentation (like JSON.stringify in JS).
>
> regards,
> Rémi
>
> - Original Message -
>
On 5/15/2025 5:27 PM, Remi Forax wrote:
It's not clear to me why JsonArray (for example) has to be an interface instead
of a record ?
Oh, you know the answer to this. A record limits us to a single
implementation with a rigid representation. Behind an interface, we can
hide lazy parsing
> From: "Ethan McCue"
> To: "Remi Forax"
> Cc: "Paul Sandoz" , "core-libs-dev"
>
> Sent: Friday, May 16, 2025 1:44:52 AM
> Subject: Re: Towards a JSON API for the JDK
> I present for your consideration the library I made when sp
- Original Message -
> > From: "Paul Sandoz"
> > To: "core-libs-dev"
> > Sent: Thursday, May 15, 2025 10:30:42 PM
> > Subject: Towards a JSON API for the JDK
>
> > Hi,
> >
> > We would like to share with you our thoughts and pl
paces used for the indentation (like JSON.stringify in JS).
regards,
Rémi
- Original Message -
> From: "Paul Sandoz"
> To: "core-libs-dev"
> Sent: Thursday, May 15, 2025 10:30:42 PM
> Subject: Towards a JSON API for the JDK
> Hi,
>
> We would
Hi,
We would like to share with you our thoughts and plans towards a JSON API for
the JDK.
Please see the document below.
-
We have had the pleasure of using a clone of this API in some experiments we
are conducting with
ONNX and code reflection [1]. Using the API we were able to quickly
58 matches
Mail list logo
