No, the spec explicitly says it must use the behaviour defined in
DecimalFormat/NumberFormat/DateFormat. Our impl is imo almost correct.
new DecimalFormat("###,####.##").format(123123123.3434d)will give you
1,2312,3123.34 when running with Locale.USand
1 2312 3123,34 when running over here in Austria.
I've now read the spec again and there is one more layer we seem to miss. Which
is JsonbConfig.withLocale(Locale) and/or it's propertyLOCALE =
"jsonb.locale"But this is afaict not being used in the TCK. So the behaviour of
the test is really depending on the country you run it in. And that's bad.
Indeed I understand what you say: if you have a Date or a Number and you
specify a @JsonbDateFormat or @JsonbNumberFormat then of course the String you
send to a client in your JSON should NOT be depending on neither the Locale the
server is running in nor the Locale the client is running in.So for me this
means that it's almost a MUST to specify a JsonbConfig where you set your
Locale to a very specific fixed value!
This is something I've also didn't care so far. Mostly because we always use
the standard ISO formats for both Dates and numbers.
LieGrue,strub
On Sunday, 20 October 2024 at 10:19:04 CEST, Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
Hi Mark
Looks like a bug where we dont enforce a default locale properly since
representation must not depend from the contextual locale.
Le dim. 20 oct. 2024 à 00:24, Mark Struberg <strub...@yahoo.de.invalid> a
écrit :
> hi!
>
> when running the latest TCK I get the following errors over here in Austria
>
> [ERROR] Failures:
> [ERROR] NumberFormatCustomizationTest.testNumberFormatAccessors:135
> Failed to correctly customize number format during marshalling using
> JsonbNumberFormat annotation on getter.
> Expected: a string matching the pattern
> '\{\s*"instance"\s*:\s*"123,456.79"\s*\}'
> but: was "{\"instance\":\"123.456,79\"}"
> [ERROR]
> NumberFormatCustomizationTest.testNumberFormatPackageTypeOverride:159
> Failed to correctly override number format customization using
> JsonbNumberFormat annotation on package during marshalling using
> JsonbNumberFormat annotation on type.
> Expected: a string matching the pattern
> '\{\s*"instance"\s*:\s*"123,456.79"\s*\}'
> but: was "{\"instance\":\"123.456,79\"}"
> [ERROR] NumberFormatCustomizationTest.testNumberFormatType:89 Failed to
> correctly customize number format during marshalling using
> JsonbNumberFormat annotation on type.
> Expected: a string matching the pattern
> '\{\s*"instance"\s*:\s*"123,456.79"\s*\}'
> but: was "{\"instance\":\"123.456,79\"}"
> [ERROR]
> NumberFormatCustomizationTest.testNumberFormatTypeFieldOverride:183 Failed
> to correctly customize number format during marshalling using
> JsonbNumberFormat annotation on type.
> Expected: a string matching the pattern
> '\{\s*"instance"\s*:\s*"123,456.8"\s*\}'
> but: was "{\"instance\":\"123.456,8\"}"
>
> Reason is likely that the numberformat is defined as
> @JsonbNumberFormat(value = "###,###.##")
> public class PackageCustomizedTypeOverriddenDoubleContainer
> But afaiu the , and . in DecimalFormat [1] does not stand for the
> character ',' and ',' but just for 'that decimal separator in your
> language' (which over here in Austria is a dot, and '.' stands for the
> comma separator (which over here in Austria is really a comma, not a dot
> like in english speaking countries).
> And that way I likely end up with getting non expected values.
> This now might be a failure in the TCK or it might be a TCK setup issue.
> But I didn't find any documents which specifies that we need to run with
> lang=en_EN
> Have I overlooked something?
>
> txs and LieGrue,
> strub
>
> [1] https://docs.oracle.com/javase/8/docs/api/java/text/DecimalFormat.html
