You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
when I execute the Test org.eclipse.yasson.documented.DocumentationExampleTest#testDateNumberFormats1 on my local system, it fails because the BigDecimal gets serialized to 123,46 instead of 123.46 containing a comma instead of a dot as decimal divider.
This might be caused by the default localization settings (german) of my local system in combination with the used test class adding a Numberformat to the field @JsonbNumberFormat("#0.00"), but I would expect the test still not to fail depending on my local settings.
I think it is a bug as the JSON specification only allows the dot . as decimal dot and not the comma , referencing to the number section https://tools.ietf.org/html/rfc7159#section-6
So the BigDecimal 123.46 should never, even not with my german local settings get serialized to 123,46 as this results in invalid JSON.
Full JUnit output of the test org.eclipse.yasson.documented.DocumentationExampleTest#testDateNumberFormats1
org.junit.ComparisonFailure:
Expected :{"birthDate":"07.08.1999","name":"Jason Bourne","salary":"123.46"}
Actual :{"birthDate":"07.08.1999","name":"Jason Bourne","salary":"123,46"}
The text was updated successfully, but these errors were encountered:
thanks for raising this issue @Simulant87, I've also raised jakartaee/jsonb-api#188 on the JSON-B spec so we can clarify this at the spec level in the future
Thank you for taking this onto the spec level, after I saw existing tests failing, I already had the feeling that this should be clarified on a higher level.
@aguibert I had again a look at the tests and now I am even thinking about rejecting my own merge request. As the input and the output of the BigDecimal is stored as a String (in quotes) in JSON the localized formatting is totally valid also in JSON as it is not a Number ( without quotes and only allowing .) but a String, that on the other side might be parsed with the same localized settings and could fail if this is not applied as expected.
I was just confused by the default picking up the system default locale to format the BigDecimal String representation and as a result the tests are not system (locale) independent.
when I execute the Test
org.eclipse.yasson.documented.DocumentationExampleTest#testDateNumberFormats1
on my local system, it fails because the BigDecimal gets serialized to123,46
instead of123.46
containing a comma instead of a dot as decimal divider.This might be caused by the default localization settings (german) of my local system in combination with the used test class adding a Numberformat to the field
@JsonbNumberFormat("#0.00")
, but I would expect the test still not to fail depending on my local settings.I think it is a bug as the JSON specification only allows the dot
.
as decimal dot and not the comma,
referencing to the number section https://tools.ietf.org/html/rfc7159#section-6So the BigDecimal
123.46
should never, even not with my german local settings get serialized to123,46
as this results in invalid JSON.Full JUnit output of the test
org.eclipse.yasson.documented.DocumentationExampleTest#testDateNumberFormats1
The text was updated successfully, but these errors were encountered: