jackson-modules-base

jackson-modules-base copied to clipboard

As per:

https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html

it seems like there is a way to actually get near-static access for getters, without (explicit) code generation, using Java 8 added class LambdaMetafactory. Whether it will actually work out or not remains to be seen -- and, if it does, could it actually be added in jackson-databind? -- but seems like a promising lead. While mechanism is probably not enough to cover all code generation needs (field access, constructor calls), getter/setter access is significant on its own.

Another useful article:

https://bytex.solutions/2017/07/java-lambdas/

Hi @cowtowncoder, I am prototyping a new Afterburner that does this: https://github.com/stevenschlansker/jackson-blackbird

Currently, we run this in production with good results, although obviously the approach is very new and requires additional proving out.

Is this something I could contribute to jackson-modules-base? It would be nice to have the source in-tree so it does not drift from Jackson versions, and it would make release management easier. Some projects have already expressed interest: https://github.com/jhipster/generator-jhipster/issues/9934

Yes, I think it would definitely make sense for Jackson 3.0, but possibly also for 2.10.

If there are some concerns about stability for 2.x, would it be possible to have an alternate backend, pluggable via module configuration, for 2.10, defaulting to current ("old") implementation, swappable by user? And if this proves to work well, then if there will be 2.11 (not yet decided), could make default.

One problem, however... is Java 8 requirement.

So maybe most practical thing is to wait until 2.10.0 is released; I think I would cut 2.11 branch (assuming there may be new version), and we could restart discussion on Java 8 as baseline. I think requiring Java 8 for Afterburner is probably perfectly fine (bit late for 2.10, but not 2.11), but who knows, maybe more generally for Jackson 2.11 components (once again excluding annotations, jackson-core, maybe jackson-jr).

Does this make sense? I am hoping to wrap up 2.10 within a month.

Currently, I am only targeting getting it merged in as a module for 2.x series. Then the dependency on newer Java only affects those who choose to use it, same as e.g. datatype-jdk8.

If that proves successful, and after the source level has moved to 8+, then we can tackle integrating it mainline. I'm excited to make that happen but I want to collect more success stories first and really make sure it's ready :)

I'll open a PR when I get a moment and it can be considered for merge before or after 2.10, it is not a big deal either way to me. Thanks!

@stevenschlansker That sounds good, I appreciate caution wrt first using it, getting module mature and field-tested. That sounds like a good plan to me. With different maven coordinates can easily publish 2.10 version, and later replace "standard" Afterburner when proven stable.