Jakarta JSON-P `Json.***` methods are crazily inefficient

[gsmet]

The low-level static method hosted in the Jakarta JSON-P Json object are very inefficient: they are resolving a JsonProvider.provider() for each call which in turn calls the ServiceLoader (among other things...) and allocate a new JsonProvider.

See:

• https://github.com/jakartaee/jsonp-api/blob/master/api/src/main/java/jakarta/json/Json.java#L433-L435
• https://github.com/jakartaee/jsonp-api/blob/master/api/src/main/java/jakarta/json/spi/JsonProvider.java#L109-L145

Meaning that when you are calling Json.createValue("string") to allocate a simple String value, you are actually making a call to the service loader and instantiating a new JsonProvider.

I stumbled upon that independently this week-end and after experimenting with it and writing a quick patch, I was like "it's crazy nobody complained about it" so I went to the JSON-P website and stumbled upon:

• #346 - Json should cache the result of JsonProvider.provider() jakartaee/jsonp-api#347 (which is the same patch I wrote)
• and then: Methods in Json re-create JsonProvider on each execution, Json should cache the result of JsonProvider.provider() jakartaee/jsonp-api#346
• and finally: Json factory methods are very inefficient jakartaee/jsonp-api#154

Meaning that I don't expect it to be fixed any time soon.

To give an idea of how things go, I did a simple JMH benchmark.

Json.createValue("test") i.e. what people (including us) use:

Iteration   1: 153.907 ops/ms
Iteration   2: 155.308 ops/ms
Iteration   3: 154.542 ops/ms
Iteration   4: 155.963 ops/ms
Iteration   5: 156.462 ops/ms

Using a static provider with JSON_PROVIDER.createValue("test"):

Iteration   1: 1112305.967 ops/ms
Iteration   2: 1114183.052 ops/ms
Iteration   3: 1113783.793 ops/ms
Iteration   4: 1111395.048 ops/ms
Iteration   5: 1112449.325 ops/ms

That's 7200+ times faster.
The createValue() methods are the ones for which it's the most inefficient as they should be extremely lightweight as called quite often.

While we are mostly using Jackson in Quarkus itself and recommending Jackson, we have several components using JSON-P and JSON-B in the SmallRye world, for instance SmallRye GraphQL and SmallRye Health.
And we have people using JSON-P/JSON-B out there because they want to stay in the MicroProfile or Jakarta world.

I know SmallRye GraphQL is affected by the inefficiencies as I have seen some direct calls to the Json methods in some runtime code (for instance here: https://github.com/smallrye/smallrye-graphql/blob/main/client/implementation/src/main/java/io/smallrye/graphql/client/impl/RequestImpl.java#L75).
From what I can see SmallRye Health is not affected as it creates a unique JsonProvider.

Note that I haven't done any benchmarks in SmallRye GraphQL, I have just verified that we were instantiating too many JsonProviders.

As for the SmallRye components, I think we should discuss this subject in the context of Quarkus as the solution we want to put in place for Quarkus might be different from the ones we want to use in the general case (for instance in WildFly).

• we might want to have an SPI to push Jackson there. I discussed it a few times with @jmartisk already but it wasn't considered top priority
• even if we do, we probably need to fix the JSON-P/JSON-B case - while fixing our JSON-P calls could be easy (at least in the Quarkus case, I'm not sure if in the case of WildFly, we would want a single provider), I don't know if JSON-B uses the Json shortcut under the hood, in which case it might make things a bit harder to handle.

[quarkus-bot]

/cc @EricWittmann (openapi), @Ladicek (fault-tolerance,smallrye), @MikeEdgar (openapi), @brunobat (tracing), @cescoffier (mutiny,reactive-messaging), @ebullient (metrics), @jmartisk (graphql,health,metrics,smallrye), @jponge (mutiny), @ozangunalp (reactive-messaging), @phillip-kruger (graphql,openapi,smallrye), @radcortez (smallrye,tracing), @sberyozkin (jwt), @xstefank (health)

[gsmet]

Hmmm, the bot shouldn't have mentioned so many people, sorry about that. We probably need to tweak this area/smallrye label.

[gsmet]

A quick workaround would be to initialize one static JsonProvider somewhere (or at least to have only one for the client and one for the server if we want to support multiple deployments and tweaking the JsonProvider but that means having the means to propagate it wherever it's needed) in the code and ban the use of Json..

Now, no idea if JSON-B uses Json so that might just be a band aid.

[jmartisk]

Regarding the WildFly/EAP case and potential multiple providers: I generally gave up on supporting multiple deployments of SmallRye GraphQL in a single WF instance. It generally works, but there are lots of potential problems where the apps are not fully isolated. In the past, I made some efforts to make it work, but it was unwieldy, so I kinda gave up. This is in line with the official support policies of the EAP XP product (see https://access.redhat.com/articles/2026253) where multiple deployments are explicitly unsupported. So I guess we could start with the quick fix of caching the JSON provider and then look into bringing in support for Jackson...

[gsmet]

@jmartisk if we are following this path, I wonder if we should make it static in Health too: https://github.com/smallrye/smallrye-health/blob/main/implementation/src/main/java/io/smallrye/health/SmallRyeHealthReporter.java#L125 .

AFAICS SmallRyeHealthReporter is instantiated twice in Quarkus due to our CDI infra so we are initializing two JsonProvider.

Probably worth discussing it with @xstefank and @radcortez .

[jmartisk]

Possibly, but given that it's an app-scoped CDI bean, it doesn't seem necessary (the problem would be obtaining the provider on each request), and having static fields in CDI beans is... weird

[gsmet]

So I kinda agree but it's still one ServiceLoader call we could avoid. I will discuss it with Martin Kouba hopefully soon.

[xstefank]

I was thinking about providing Jackson API in SR Health, but we need to be aligned with JSON-P for spec. But I personally don't see what's so wrong with a static field for this since it's really just utility for marshaling. @mkouba mentioning you so you chime in.

[mkouba]

AFAICS SmallRyeHealthReporter is instantiated twice in Quarkus due to our CDI infra so we are initializing two JsonProvider.

It's instantiated twice because it's an @ApplicationScoped bean so one instance is the client proxy which is a subclass of SmallRyeHealthReporter. And the same applies to all those collections and maps, such as SmallRyeHealthReporter#livenessUnis. We could initialize the state in the @PostConstruct callback. For JsonProvider I think it should be ok to use a static final field instead. However, we need to make sure the constant is initialized at the right time, i.e. when the correct provider is available.