-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG][JAVA] Deserialization of array with uniqueItems=true doesn't preserve order #10167
Comments
When using Jackson, arrays with uniqueItems=true gets deserialized to HashSet rather than LinkedHashSet, thus not preserving order as expected.
When using Jackson, arrays with uniqueItems=true gets deserialized to HashSet rather than LinkedHashSet, thus not preserving order as expected. - Added the @JsonDeserialize annotation on the setter of arrays with unique items.
When using Jackson, arrays with uniqueItems=true gets deserialized to HashSet rather than LinkedHashSet, thus not preserving order as expected. - Added the @JsonDeserialize annotation on the setter of arrays with unique items.
With the new version 5.3.1 the JsonNullable handling ist broken The PR (#10241) broke the JsonNullable deserialization. If you use a JsonNullable with uniqueItems. This code will generated: e.g.
Exception
|
@borsch can you please take a look at this issue when you've time? Thanks. |
@borsch it is at all possible to specify a concrete implementation in a wrapper. You can't do that with optionals either, right? |
@MelleD I believe it doesn't. Most likely JsonNullable+Set still would have default impl - HashSet |
I'm not a Jackson expert either, maybe it's possible with an own serializer. I'll ask at stackoverflow. If I find a solution, I'll do a PR . Are you doing a PR to make it work again with JsonNullable? |
@MelleD not yet |
Thanks for the quick PR. Did you enable the Optional feature? I have never used the option, but not that in the constellation is also broken. |
@MelleD I haven't heard about such feature. Can you give an example how to enable it? I'll test it later |
@borsch Ah i think is just for parameter in the API classes |
@MelleD yep |
FWIW - I am trying to add |
@welshm The idea has come up a few times. What don't you like about the JsonNullable? |
They can both be used - in my view they solve different problems. I see three use cases. If a value is not required to be present but If a value has If a value is required and |
Yes that's correct JsonNullable is just for the Tristate and in the moste cases for the json patch. |
I see the first case as when I would want Optional over JsonNullable - a value is not required to be present in the JSON schema, but if it is present it must not be
Assuming a patch request...
|
A required/mandatory field should never be Optional or JsonNullable. This contradicts the principle of mandatory. With required it can no longer be missing in the payload. But this is an important status for an ignore. Missing in payload (required or not). Here ist the difference use direct value String vs JsonNullable /Optional Currently you have no chance how you can decide use Optional or JsonNullable |
Sorry you're right, I hadn't reasoned about it properly for required - but my point still stands about an optional value that cannot be null. I think that JsonNullable can handle all cases Optional does. As long as, if If a field is optional and not nullable - I think Java Optional is preferred as it removes the error of |
I know what you are trying to achieve and that makes sense in many use cases. The question is whether the value null has a semantic meaning like reset. The problem is currently the specification and yaml. You currently have no chance to use both in one generator, i.e. you have to decide either Optional or JsonNullable. As soon as you patch an endpoint with e.g. Json merge you have to (unfortunately) pass through the JsonNullable for all optional fields although null may have no meaning or you have to just get normal fields with null value. I don't know if the specification allows additional fields in the yaml. With an additional field you could map what you have in mind. |
Let's move the conversation to #11384 as it's tangential to this bug at this point? |
After #5254 was fixed and merged, when using Jackson, arrays with uniqueItems=true gets deserialized to HashSet rather than LinkedHashSet, thus not preserving order as expected.
Even though the field (myProp) is initialized to an empty LinkedHashSet, it is promptly overwritten with a regular HashSet given that there is no deserialization-hint (@JsonDeserialize(as = LinkedHashSet.class)) on the setMyProp-method. The method invoked looks like this:
and thus there is no way for Jackson to understand that order needs to be preserved.
This issue is present in version 5.2.1
The text was updated successfully, but these errors were encountered: