Enabling Jackson reflection-free serializers for Quarkus REST by default in 3.35

[Guillaume Smet]

Hi,

In Quarkus 3.35, we plan to enable Jackson reflection-free serializers for Quarkus REST by default.

Mario posted a blog post about it here: https://quarkus.io/blog/reflection-free-jsckson-serializers/ .

We would welcome you testing this feature already to report any issue, especially if you are using non default Jackson features.

Mario is actively working on fixing the issues people report (such as in https://github.com/quarkusio/quarkus/pull/53559) so the more the merrier.

Thanks.

-- 

Guillaume

[Eric Deandrea]

I turn this in by default in all my projects and have been for some time now. 

———————
Eric Deandrea
Java Champion
Sr. Principal Software Engineer
Red Hat North America
edea...@redhat.com

Sent from a mobile device

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo88BmR%2BskJ005oxnLhXrLy1JixCQP8KtnTRJ95nRo%3DZug%40mail.gmail.com.

[Paul C-B]

Tried this now and our thousands of test cases all ran fine... But how
do i know it actually did anything :-)

[Mario Fusco]

Tried this now and our thousands of test cases all ran fine... But how
do i know it actually did anything :-)

The idea is indeed that if everything works fine you shouldn't see any difference :)

One way to check if the necessary reflection-free (de)serializers are generated as expected is to add this to the application.properties

    quarkus.package.jar.decompiler.enabled=true 

and check if they are written in the target/decompiler/generated-bytecode folder.

That said you should also see some positive impact on performance. Did you (or anybody else) try to measure if it makes any performance difference?

I'm not sure how else you could check this, do you have any better suggestions? 

Thanks,

Mario

[Paul C-B]

Ok all good. I'll try some load tests as well.

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z4iDjuCbQ880Hrajt4_ckp7PAjyWZ1-_L_KaiKcb2iYkw%40mail.gmail.com.

[Guillaume Smet]

@Paul I would also be interested in build time metrics e.g. does it make the build slower for you and to what extent.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMd%3DrQ-S3WwZJ8jiiiY1Yc_ekq%2Bb%2BGGkBoxFcVXD%3DYoJKzirYw%40mail.gmail.com.

[Paul C-B]

Without the setting (3 runs):
Quarkus augmentation completed in 10765ms
Quarkus augmentation completed in 11861ms
Quarkus augmentation completed in 10242ms
With the setting (3 runs):
Quarkus augmentation completed in 10354ms
Quarkus augmentation completed in 10374ms
Quarkus augmentation completed in 11912ms

The decompiler dir was 6MB larger with the setting on

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_YE5oKTCtK9fdAq4Zr24zCt0ZW543p9LBkjEeV0cJr7w%40mail.gmail.com.

[Paul C-B]

Results of a heavy JSON performance test (over 100MB/s of JSON)

Flame graph before:


After:

[Paul C-B]

Is there a way of using this when doing serialisation and
deserialisation using ones own
@Inject
ObjectMapper jacksonMapper;

We use our own Rest Client on top of the vertx http client that
predates the Quarkus rest client and that uses jackson for the
mapping.

[Mario Fusco]

So, if I understand correctly, the reflection-free serializers bring an improvement around the 5% in both throughput and latency.

Not bad I guess, but maybe I expected a bit more, or in reality I didn't know exactly what to expect :)

Can you share the code of your harness? Is there a way I could reproduce those results? 

Also can you please share the original browsable flamegraphs? Those screenshots are not very readable and it is hard to tell what's going on there.

@Holly Cummins @Eric Deandrea @Guillaume Smet @Francesco Nigro Do you think this could be a good topic for a future Quarkus Insights? (when I will have more data to discuss)

On Mon, Apr 13, 2026 at 6:59 PM Paul C-B <bcl...@gmail.com> wrote:

Is there a way of using this when doing serialisation and
deserialisation using ones own
@Inject
ObjectMapper jacksonMapper;

We use our own Rest Client on top of the vertx http client that
predates the Quarkus rest client and that uses jackson for the
mapping.

I don't think this is possible at the moment, but to be honest I'm not fully understanding your use case. Can you please also share an example of it, so I could give a look? 

Thanks,

Mario

[Paul C-B]

Hi Mario,

I'll send details when I get a chance but this is a real-world product
with chained rest calls and DB access etc so the JSON overhead is only
a fraction of the overall CPU load

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z6rakr1HsHgV_OZP%3D7c0jjVxv6DkO1EvgqfXbQLxPND4Q%40mail.gmail.com.

[Paul C-B]

In terms of our rest client:

We use the vert.x mutiny http client to do HTTP calls passing JSON
Bodies. E.g. something like (pseudocode):

@Inject
ObjectMapper jacksonMapper;

SomeObject obj = new SomeObject();
obj.setName("Hello");
obj.setAge(10);

io.vertx.mutiny.core.http.HttpClient httpClient =
io.vertx.mutiny.core.Vertx.newInstance(vertx).createHttpClient(options);

String myJson = jacksonMapper.writeValueAsString(obj);
Uni<HttpClientResponse> responseUni = httpClient
.request(requestOptions)
.onItem()
.transformToUni((HttpClientRequest request) -> {
log.debug("Sending request body");
request.send(myJson);
});
Then when we get the response we buffer the result and deserialise
back to an object using jacksonMapper

So you can see, the new feature uses the non-reflection serialisers
and deserialisers for JaxRS request/responses hosted by Quarkus but if
inside Quarkus one wants to serialise and deserialise using jackson,
how can one:
1) Mark a POJO as needing to be build time generated for this optimisation
2) Have a objectMapper that uses these serialisers and deserialisers
that can be used by user code at runtime

FYI we already have a customizer that implements
ObjectMapperCustomizer. Maybe something like calling Quarkus with our
mapper and give it the opportunity to enrol the optimised classes:

@Override
public void customize(ObjectMapper jacksonMapper) {
Quarkus.addOptimizedSerializers(jacksonMapper);
Quarkus.addOptimizedDeSerializers(jacksonMapper);
... rest of our own user level customizations

[Mario Fusco]

I'll send details when I get a chance but this is a real-world product
with chained rest calls and DB access etc so the JSON overhead is only
a fraction of the overall CPU load

Ah ok, I missed that. Well, I guess that in this case a 5% improvement only because of this reflection-free Jackson serialization can be considered a very good result.

Mario 

[Paul C-B]

Here is the flame graph. Its of our system under a load test. Probably
best explained on a call but the flow at a high level (this is an API
gateway (called conductor)) and microservices all bundled together as
a single jar but the flow is actually via http from the API gateway
back into the same process:

1) Load test (wrk) calls rest endpoint (resteasy reactive) (optimised
deserialisation)
2) Endpoint uses vertx httpclient to call microservice (normal
jackson serialisation)
3) Microservice receives request (optimised deserialisation) and does
JPA stuff to read DB
4) Microservice responds with JSON (optimised serialisation)
5) http client from (2) receives response and deserialises (normal
jackson deserialisation)
6) Step (1) returns (optimised serialisation)

You will see the calls to JsonImpl in the flame graph where the normal
jackson is used

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z6W%2BGZLDaxEnXqujkHsya8DsvEB0veweYrmEszpGrFxzA%40mail.gmail.com.

[Georgios Andrianakis]

On Mon, Apr 13, 2026 at 7:59 PM Paul C-B <bcl...@gmail.com> wrote:

Is there a way of using this when doing serialisation and
deserialisation using ones own
@Inject
ObjectMapper jacksonMapper;

We use our own Rest Client on top of the vertx http client that
predates the Quarkus rest client and that uses jackson for the
mapping.

Hey Paul,

We've delibirately been very concervative with the reflection-free Jackson stuff, which means they will not be used outside of the very specific scenario outlined in the docs

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMd%3DrQ89EkpL_nCu7N9bSObrQjqxRhV6H3r4LuPMgvU2Kw8Yxg%40mail.gmail.com.