Yep, but this also means in johnzon we can force en (not sure if root would work) locale by default to have a Double.tostring/parse behavior and everyone would be happy - but agree spec should explicit it too.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 20 oct. 2024 à 11:21, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > 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 >
