Generating code at compile time a la Moshi?

17 views
Skip to first unread message

Adam Zell

unread,
May 16, 2020, 12:25:09 AM5/16/20
to jackson-user
With the popularity of Java frameworks that enable native images rising (Quarkus, Micronaut, Helidon, Spring Boot, etc.), minimizing reflection is becoming a best practice.

JSON parsers like https://github.com/square/moshi/#codegen and https://github.com/ngs-doo/dsl-json#java8-annotation-processor can remove or minimize run-time reflection by utilizing code generation.  Is there an interest in supporting the same feature in Jackson?  I am assuming that https://github.com/FasterXML/jackson-docs/wiki/Presentation:-Jackson-Performance#compatible-easy-afterburner does something similar but again at run-time.

Thanks!

Tatu Saloranta

unread,
May 16, 2020, 12:32:07 AM5/16/20
to jackson-user
On Fri, May 15, 2020 at 9:25 PM Adam Zell <zell...@gmail.com> wrote:
>
> With the popularity of Java frameworks that enable native images rising (Quarkus, Micronaut, Helidon, Spring Boot, etc.), minimizing reflection is becoming a best practice.
>
> JSON parsers like https://github.com/square/moshi/#codegen and https://github.com/ngs-doo/dsl-json#java8-annotation-processor can remove or minimize run-time reflection by utilizing code generation. Is there an interest in supporting the same feature in Jackson? I am assuming that https://github.com/FasterXML/jackson-docs/wiki/Presentation:-Jackson-Performance#compatible-easy-afterburner does something similar but again at run-time.

There probably is interest, as there are cases where this would be
beneficial, but I am not aware of anyone working on this.
There are couple of aspects to runtime introspection; in particular
annotation access (typically "one-time" overhead for inspecting all
annotations to figure out settings for (de)serializers), and then
actual property set/get via reflection.
Afterburner does second case, dynamically (so after usual annotation
introspection dynamic accessors and constructor callers are
generated).

I suspect both cases could be covered, possibly separately. First case
(annotation access) alternative could, for example, be exposed via
different `AnnotationIntrospector` feeding settings, and could be
useful for reducing start-up overhead on serverless platforms,
and Android (where annotation access is hideously slow for some reason).
Second case (generating accessors) can be addressed in many ways as
well; some tools generate source code to compile (and I think this is
nowadays more common one, and probably easier). Extending Afterburner
could theoretically work, but one problem is that Afterburner uses
standard reflection access as fallback where needed, and this is
probably not something that would be practical if all reflection
access was to be replaced.

-+ Tatu +-
Reply all
Reply to author
Forward
0 new messages