-
Notifications
You must be signed in to change notification settings - Fork 175
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
Field order mismatch after serialization and deserialization #842
Comments
Quick question: version affected is listed as 2.17.2 -- but how about 2.18.0. Or, assuming 2.18.0 affected, would it be possible to test with 2.18.1-SNAPSHOT (of both https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.18.1 and in particular, one of: |
For version |
Running Parcelo in a container via our current Dockerfile revealed that "uses-sdk" fields were not being parsed from applications' Android manifests, effectively preventing app uploads since the targetSdk property of uses-sdk is required by Parcelo. This bug wasn't caught until now because it only seems to manifest itself when running via the Dockerfile; running locally as in our recommended development environment does not have the issue. The Jackson 2.18.0 upgrade has not yet been included in a production release, so it's uncertain whether the issue would have surfaced in our production environment. We tracked the issue down to a regression in Jackson 2.18.0. The exact cause is unknown. However, a number of seemingly related issues were reported for Jackson 2.18.0 [1], so we plan to closely monitor those issues and test upcoming Jackson releases carefully to prevent breakage. [1]: See below: - FasterXML/jackson-module-kotlin#841 - FasterXML/jackson-module-kotlin#842 - FasterXML/jackson-module-kotlin#843 - FasterXML/jackson-module-kotlin#832 - FasterXML/jackson-databind#4508 - FasterXML/jackson-databind#4752
Running Parcelo in a container via our current Dockerfile revealed that "uses-sdk" fields were not being parsed from applications' Android manifests, effectively preventing app uploads since the targetSdk property of uses-sdk is required by Parcelo. This bug wasn't caught until now because it only seems to manifest itself when running via the Dockerfile; running locally as in our recommended development environment does not have the issue. The Jackson 2.18.0 upgrade has not yet been included in a production release, so it's uncertain whether the issue would have surfaced in our production environment. We tracked the issue down to a regression in Jackson 2.18.0. The exact cause is unknown. However, a number of seemingly related issues were reported for Jackson 2.18.0 [1], so we plan to closely monitor those issues and test upcoming Jackson releases carefully to prevent breakage. [1]: See below: - FasterXML/jackson-module-kotlin#841 - FasterXML/jackson-module-kotlin#842 - FasterXML/jackson-module-kotlin#843 - FasterXML/jackson-module-kotlin#832 - FasterXML/jackson-databind#4508 - FasterXML/jackson-databind#4752
Search before asking
Describe the bug
I am encountering a problem where the field order is not preserved after serializing and deserializing objects in Jackson.
I need access to only one specific field (transactionId), while I want to pass the remaining fields as they are, preserving the order in which they appear. I expected the transactionId field order might change, but I did not expect the order of the other fields
(a, b, c)
to change, especially in the second and third tests (SecondObject and ThirdObject). The data inside thec
array is preserved in the expected order, but the surrounding fields are re-ordered.To Reproduce
Tested Objects:
Input JSON for tests:
Test Case:
Here’s a test case to reproduce the issue. The following Kotlin test serializes and deserializes three different classes (FirstObject, SecondObject, and ThirdObject), comparing the serialized JSON with the original input JSON.
JacksonSortingTest.kt.
First Test Result (Passes):
The first test for FirstObject passes as expected, with the field order being preserved.
Failing Test Results:
Expected:
For SecondObject was:
For ThirdObject was:
Repository for Reproduction:
You can find a repository with the full reproduction of the issue at jackson-databind-sorting-issue.
Expected behavior
For SecondObject and ThirdObject, after serializing the object back to JSON, I expect the
transactionId
field to appear at the top, followed by the fieldsb
,a
, andc
, in the exact order they were present when the JSON was deserialized into SecondObject and ThirdObject.Versions
Kotlin: 2.0.0
Jackson-module-kotlin: 2.17.2
Jackson-databind: 2.17.2
Additional context
This issue is a duplicate of 4751. I'm trying to reproduce it with Java, but it seems like all the described cases are specific to Kotlin
The text was updated successfully, but these errors were encountered: