RFR: 8297091: New langtools test jdk/javadoc/doclet/testValueTag/TestValueFormats.java fails on machines with unexpected number format

[Pavel Rappo]

On Thu, 17 Nov 2022 22:10:28 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > Generally, there are two ways to fix issues like this:
> > 
> > 1. force the locale to be as needed
> > 2. accommodate the locale being used
> > 
> > 1 is simpler; 2 seems like a better solution.
> 
> Not sure I understand correctly - Option 1 would mean that a locale can be picked by some setting and Option 2 means the current behavior - use the system locale, right? But how would option 1 then be simpler than option 2, given that I perceive option 2 as current status quo? 😄
> 
> However, with option 2, I guess my proposed testfix would be the right thing to do, correct?
> 
> > In general, we don't do a lot of testing in non-English locales. (Our bad.). Is this the only (javadoc?) test that fails?
> 
> I'm only aware of this one ATM.

My take is that Option (1) is "golden output". You fixate the locale and capture the output. Then every run you force that same locale (yes, there's a javadoc option called `-locale`) and compare the output of the run with the golden output.

Option (2) is "property testing". You assert some property of the system. In this case, the property, albeit a bit implicit, looks something like this: 

    whatever locale is effective for this javadoc run, is used by `@value` to format its arguments

Your test additionally assumes that "if no locale is specified, the default locale is used". Which is true.

-------------

PR: https://git.openjdk.org/jdk/pull/11177