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
Hi Paul,
I like the emphasis on minimality, and extensibility of the proposed API.
One comment/question is why the API choses to expose Json arrays and
objects as List/Maps respectively, instead of e.g. providing accessor to
the object members/array elements.
E.g. it seems to me that creating
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
Developers use JSON libraries like Fastjson, Jackson and Gson primarily
(my claim) because they can marshal between JSON files and POJOs in one
line of code with great performance and can easily tweak the mapping
using annotations or adapter classes.
Being able to read/write a JSON file from/to
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
+1 for having a JSON battery included with the JDK. And for "Our primary goal is
that the library be simple to use for parsing, traversing, and generating conformant JSON
documents."
Generating JSON could be easier. Why not convenience methods Json.newObject and
Json.newArray like in https://g
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 outside the ken of i'd say most. I'd be interested in an
expe
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
something implementing an
interface differently).
On Fri, May 16, 2025 at 2:26 PM wrote:
>
>
> --
>
> *From: *"Ethan McCue"
> *To: *"Remi Forax"
> *Cc: *"Paul Sandoz" , "core-libs-dev" <
> core-libs-
> 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
As the API intentionally uses interfaces to open the ability to optimize
the implementation, it would be also just straightforward to not limit
the text source to the explicit class String. When instead allowing the
general interface CharSequence, *any* kind of text source can be parsed,
for ex
Hi Rémi,
On 5/15/25 2:27 PM, Remi Forax wrote:
Hi Paul,
yes, not having a simple JSON API in Java 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
- 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:
Ahh, as expected some great thoughts have gone into this. :-)
Allowing the ignore of comments when parsing is not "inventing a new
format", IMO. More so because the RFC allows it (section 9) and because
it would be strictly opt-in. So the parser can still be said to be
strictly RFC-8259 while opt
I would like to add JSON comments from my perspective.
I had a requirement of working with JSON in java multiple times during
working on the university assignments recently. Since those are small,
often one-time-open projects, I did not want (or, often, it was forbidden
by assignment) to pull in w
At first, we were hopeful that we could jump right to JSON5, which
appears at first glance to be a strictly lexical, more permissive
grammar for JSON (supporting comments, trailing commas, more flexible
quoting, white space, etc.) If that were actually true, this would have
been a slam dunk, s
Great work.
I feel the elephant in the room needs to addressed: JSON comments. I
haven't tested the proposed lib but I cannot see it mentioned so I'm
assuming that comments are not supported.
For better or worse, the use of jsonc (JSON with comments) is everywhere
in some ecosystems. Unsurprisi
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
I present for your consideration the library I made when spiraling about
this problem space a few years ago
https://github.com/bowbahdoe/json
https://javadoc.io/doc/dev.mccue/json/latest/dev.mccue.json/dev/mccue/json/package-summary.html
Notably missing during the design process here were patter
Hi Paul,
yes, not having a simple JSON API in Java 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.
56 matches
Mail list logo
