Rewrite Bean Property Introspection logic in Jackson 2.x

[cowtowncoder]

Describe your Issue

We need to rewrite the Bean Property introspection (see #3719 for background); and while this is ambitious undertaking, I think it should be done in Jackson 2.x timeframe, not 3.x. That way code remains potentially mergeable from 2.x to 3.x.

The main drivers for rewrite are to solve problems that are difficult if not impossible to solve with the current mechanism:

1. Merging of annotations between Field/Method accessors and Creator (constructor/factory method) arguments
2. Handling of Record types and in particular alternate (non-canonical) constructors
3. Support for canonical constructors for non-Java JVM languages (Kotlin, Scala)

This issue is an umbrella ticket as refactoring will likely be spread across multiple PRs; they can all refer to this issue,

[cowtowncoder]

Started reading the code and clearly more of code wrt Creator detection needs to move from BeanDeserializerFactory/BasicDeserializerFactory (later part of processing) into POJOPropertiesCollector (earlier part of processing).

But not sure whether to try to move abstractions from Factory part, or rewrite; and whether to try move things incrementally or not.

Started removing deprecated methods from code paths, to help isolate actual in-use code.

[JooHyukKim]

But not sure whether to try to move abstractions from Factory part, or rewrite; and whether to try move things incrementally or not.

If we agree that we have enough test coverage, I guess.... rewrite, move big-step-incrementally?

[cowtowncoder]

@JooHyukKim Yes, I think test coverage is sufficient to allow refactoring. I am struggling at finding the steps tho. Especially in a way that would allow merging 2.18 -> master.
So it's not yet about mechanics but even conceptually which things to move or rewrite/re-implement.

And one problem part is that the latest BeanDeserializerFactory code for processing Creators relies on [Basic]BeanDescription, which would not be available during POJOPropertiesCollector (since BeanDescription is mostly used as wrapper for actual POJOPropertiesCollector.

[cowtowncoder]

Ok one big challenge that is coming up now, looking through functionality in BasicDeserializerFactory is the coupling to deserialization side in general (DeserializationConfig and DeserializationContext), and also dependency on context (DeserializationContext). This because POJOPropertiesCollector only operates on generic MapperConfig (base config of DeserializationConfig and SerializationConfig), and does not need or use context.
Dependencies are not trivial to remove; but they are also not exactly essential. But just means it is not easy to start by "lift-and-shift"ing (that is, by basically moving code from one place to the other), some rewriting required.

In the meantime I am making small incremental changes, including removal of deprecated code in affected areas.

[JooHyukKim]

Right. Also from my experience, many times it was necessary to both modify existing and add additional "internal" structure to make the code base in better shape. More of "tidy up just before making changes".

Just out of curiosity, are we going to introduce POJOPropertiesCollector, RecordPropertiesCollector and such for new version? This question is just from my imagination 😆. I am asking this because, though not necessary, if there's any plan in written format that I can refer to, so I can help.

[cowtowncoder]

Just out of curiosity, are we going to introduce POJOPropertiesCollector, RecordPropertiesCollector and such for new version? 

Not planned yet. I am thinking it should be possible to make things work without fully separate implementation. But of course if it becomes necessary that could be done.

At this first I would really want to make existing logic work same as now, but get Creator properties discovered around time others are... so move it out of BasicDeserializerFactory into either POJOPropertiesCollector or where BasicBeanDescription is resolved.

[cowtowncoder]

Hmmmh. Despite incremental refactoring, I don't think functional from BasicDeserializerFactory can moved as-is into POJOPropertiesCollector -- it does "too much", including instantiation of deserializers and so on.
So what we need is a subset. Need to re-think things a bit.

...

Ok. So, in POJOPropertiesCollector I think handling needs to incorporate selection of actual Creator method and NOT just individual properties. And that information will then be used by BasicDeserializerFactory.