Towards a JSON API for the JDK

[Daniel Gredler]

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 wave of
"serialization gadget" exploits providing RCE, followed by a wave of
denial-of-service vulnerabilities. As a user, I'd love to know that these
issues have all been considered up front:

- Serialization gadgets (no object mapping, so not an issue?)
- Sane limits (and maybe configurability) for:
  - Max object / array nesting depth
  - Max key (field name) length
  - Max value length (strings)
  - Max value length (numbers)
  - Max overall document size (maybe less of a problem if there are no
Json.parse() methods for streams or files?)

If you want to avoid the configurability aspect, it should be possible to
find defaults which are relatively safe and do not impact 99% of users
(e.g. who realistically uses JSON nested over 1k levels deep?).



On Fri, May 16, 2025 at 7:26 PM Raffaello Giulietti <
raffaello.giulietti at oracle.com> wrote:

> 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
> > explicitly copy its content into a temporary in-memory String
> > representation, upfront to parsing. More flexible, more speed, less
> > memory, less GC. :-)
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/ccb84f14/attachment.htm>