Implementing #1467: Support for @JsonUnwrapped in @JsonCreators

[fxshlein]

(fixes #1467 -- one of oldest highly-voted-for open issues)

I was more or less just messing around with an approach to solve this for now without the big refactor mentioned in the issue. Perhaps this is already fine? The test I added is green at least, but I have no idea what I might have missed. After all, if an "object with three properties" test covered a considerable amount of jackson's feature set, I wouldn't be using it... 😆

[cowtowncoder]

Could you move these back to where they were? (I assume IDE just reordered them automatically).

(we finally have Coding Style Guide -> https://github.com/FasterXML/jackson/blob/master/contribution/jackson-coding-style-guide.md

that explains intended ordering)

[cowtowncoder]

Whoa! Impressive work. I share your suspicion wrt test coverage (lack thereof), but it is what it is.

I'd need to read this through with more thought and focus to see if there's anything specifically that wouldn't work (or be against design). In the meantime I added some notes on code style issues (which are obviously not super important but might as well mention now).

Also, assuming we get through this to merge it, one thing needed (if not already done) is CLA:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

which we need before merging the first contribution. It's usually easiest to print, fill & sign, scan/photo, email to cla at fasterxml dot com. Only needed once, good for all future contributions.

[fxshlein]

@cowtowncoder I sent the signed CLA to cla@.... 🙂

Just to verify, here it says to email the CLA to info@..., are both fine?

[cowtowncoder]

... and if isUnwrapped() is not actually needed, can drop this Set and code that maintains it.

[fxshlein]

Removed the set and the check!

[fxshlein]

I noticed a minor issue with the placeholder name: If you use two @JsonUnwrapped parameters in a creator without explicitly giving it a name @JsonProperty, they will be marked as duplicates, as they both get the placeholder:

Caused by: java.lang.IllegalArgumentException: Duplicate creator property "@JsonUnwrapped" (index 2 vs 3) for type ...

I added a test case here:
https://github.com/FasterXML/jackson-databind/pull/4271/files#diff-1b40e79714a359efac38026f7dfe9dbf45f4def1877d805437ba48955ae9478eR68-R96

From what I can see, there are three solutions to this:

1. Just let it happen, maybe add a special exception message that tells users to simply distinguish the properties using @JsonProperty. On one hand this should fit right in, as the user probably has to have @JsonProperty on all parameters anyways, but on the other hand it would be kind of weird since the name is never actually used.
2. Change the placeholder to include the index ("unnamed @JsonUnwrapped property at N"). This is the one I implemented now, which makes the test case work. This is nice since the name is more unique, and the names also double as human-readable identifiers in error messages.
3. Do a refactor to allow unwrapped properties to bypass all the places where properties are placed in a map, using their name as a key. I started this here: fxshlein@3bd10a0, but it's already a pretty massive undertaking without even touching everything.

[cowtowncoder]

To me (2), adding index for bogus name, sounds reasonable at this point. +1.

[wingsofovnia]

While looking for a stop-gap solution for this in GitHub, I found this (usage) rather straightforward solution for @JsonUnwrapped support in Kotlin data classes. Perhaps this might be helpful for you or others who seek a temp solution.

Looking forward to having this merged. Thank you for the contribution!

[eranl]

@cowtowncoder, what's the status of this PR?

[JooHyukKim]

@eranl The submitter stop working 6months ago. Unless target issue is highly voted, it would be reasonable to say that there is small chance of merging unless @fxshlein or someone else picks it back up

[cowtowncoder]

Quick note: this would need to be re-based on 2.18 which may be tricky due to major POJO property introspection rewrite (or might be easy). This won't be merged in 2.17 due to high risk of regression for patch.
If rebased against 2.18, merging could be considered; definitely the problem to solve is worth tackling.

[cowtowncoder]

Re-based, but now there are conflicts to resolve... not sure I have time to tackle those right now.

[cowtowncoder]

Ok. Had a look and... yeah, no. These merge conflicts are actually beyond my repairing.
I think I broke this pr, unfortunately; it would need to be re-created starting from 2.18 branch.
The problem is that lots of code was removed from src/main/java/com/fasterxml/jackson/databind/deser/BasicDeserializerFactory.java and replaced with additions in src/main/java/com/fasterxml/jackson/databind/introspect/POJOPropertiesCollector.java.

Unfortunately those 2 classes were heavily modified by this PR.

But if anyone has time and interest to reconstruct this PR based off 2.18, we could consider it (or, in near future when 2.18 released, against 2.19).

[fxshlein]

@eranl The submitter stop working 6months ago. Unless target issue is highly voted, it would be reasonable to say that there is small chance of merging unless @fxshlein or someone else picks it back up

I'm sick at the moment, but maybe I can give it a shot later this week. I was just waiting for the PR to be merged tho, as far as I was concerned nothing was left to do, right? As far as the last comment, I had already implemented the second solution, I was just presenting alternatives. Maybe that caused a misunderstanding, sorry!

[cowtowncoder]

@fxshlein Unfortunately as per my comment, PR's changes heavily conflict with the POJO property discovery rewrite in 2.18. And being essentially a new feature (although not technically API change), I wouldn't want to sneak it in a patch release of 2.17 -- it needs to go in a .0 version of a minor version. Right now that'd be 2.18.0 via 2.18 branch.

I wasn't able to quite see how to resolve conflicts of this PR, but of course if you can figure it out, we can use this PR. Alternatively it may be simpler (if more work) to start with 2.18 and re-create changes -- logic of POJO property discovery hasn't changed (minus bug fixes), just implementation.

[fxshlein]

haha, I already figured when I saw the 2.18 RC a few days ago. Changed it to 2.19!

[fxshlein]

@cowtowncoder I changed the base branch to 2.19, seems to work without conflicts. I guess this could be merged now that the 2.19 branch exists, right?

[wingsofovnia]

Is there any update on this or reason why this isn't getting merged? Looks all green and all feedback addressed.

[JooHyukKim]

Is there any update on this or reason why this isn't getting merged? Looks all green and all feedback addressed.

We need proper planning wrt timing on when features get merged.
And this is not the only feature waiting to get merged.
Read some more and you will see Tatu saying...

Quick note: due to timing, this won't make it in 2.18, too risky.

Not to mention @since 2.18 is already outdated.

[fxshlein]

Is there any update on this or reason why this isn't getting merged? Looks all green and all feedback addressed.

We need proper planning wrt timing on when features get merged. And this is not the only feature waiting to get merged. Read some more and you will see Tatu saying...

Quick note: due to timing, this won't make it in 2.18, too risky.

Not to mention @since 2.18 is already outdated.

Note that the target branch for this PR is the development branch for 2.19, and I changed everything to @since 2.19 a while ago already, so I think the comment regarding 2.18 timing should be addressed. The timing issue was that, when I updated the PR to target 2.18, the release candidate for 2.18 was already out, at which point it makes no sense to add additional features. I think for 2.19 it should be fine to merge this right?

[cowtowncoder]

This is on my TODO list -- I have been bit overloaded with backlogs but should be able to check this out this week. Thank you everyone for your patience!

[cowtowncoder]

Went over this once, made tiny stylistic changes but want to go over the thing once more and then get merged. My spider sense is tingling wrt this being possibly risky, still, but at the same time all tests, added ones and old, pass -- and this would solve one of only 8 "most-wanted" issues, so clearly many users would like to see it come available.
So will get this merged, just want to be as sure as I can.

[cowtowncoder]

LGTM. Bit worried about possible name clashes, POJOPropertiesCollector, but can deal with problems if they arise.

[JooHyukKim]

Great job and patience @fxshlein ✌🏼!

[cowtowncoder]

Agreed. Now if I can get this cleanly merged into 3.0 that's the real test... except for one aspect, got it done. So am hopeful still.