Skip to content
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

bugfix 319 fix invalid BigDecimal serialization because of locale #320

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

bugfix 319 fix invalid BigDecimal serialization because of locale #320

wants to merge 2 commits into from

Conversation

Simulant87
Copy link
Contributor

fix #319

Signed-off-by: Simulant <nfaupel.dev@gmail.com>
Copy link
Member

@aguibert aguibert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution @Simulant87! Just one minor change requested and then we can merge

@@ -49,7 +50,7 @@ public AbstractNumberDeserializer(Class<T> clazz, Customization customization) {

final JsonbNumberFormatter numberFormat = getCustomization().getDeserializeNumberFormatter();
//consider synchronizing on format instance or per thread cache.
final NumberFormat format = NumberFormat.getInstance(jsonbContext.getConfigProperties().getLocale(numberFormat.getLocale()));
final NumberFormat format = NumberFormat.getInstance((Locale.ENGLISH));
((DecimalFormat)format).applyPattern(numberFormat.getFormat());
format.setParseIntegerOnly(integerOnly);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

going with the same train of thought not allowing commas in JSON numbers, I think we should also call format.setGroupingUsed(false) here, because people may try to use a number format like ###,##0.00 which could output a number like 123,456.78 and should be serialized as 123456.78 according to RFC 7159

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated this and also the test to cover it. But there are other test failing:
org.eclipse.yasson.customization.NumberFormatTest#testDeserializer
org.eclipse.yasson.customization.NumberFormatTest#testDeserializeWithoutClassLevelFormatter

I am unsure if I should just adopt the expected behavior/input data to my new implementation to let them pass as this changes current behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while I think this behavior proposed in this PR is technically correct, some existing users may be depending on the behavior and it would be good to not break such users in a micro release.

Since we have a major/minor release of JSON-B on the horizon, I am thinking we should defer this PR to a later release. Is that OK with you @Simulant87 or do you urgently need this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is OK with me and I totally agree that because of the changed behavior it should be part of a major- and not part of a minor-release. I am not depending an a fix.

@aguibert aguibert added the bug Something isn't working right label Aug 30, 2019
Signed-off-by: Simulant <nfaupel.dev@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working right
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: BigDecimal serialized with comma as decimal divider
2 participants