RFR: JDK-8149565: -locale option issues

[Jonathan Gibbons]

LanguageTag seems to be recommended, but to provide temporary 
compatibility, the doclet converts '_' to '-' to allow the old usage.

An arguably better solution would be to try the string unmodified, and 
only if it fails, try converting '_' to '-' and see if that is better 
... if that succeeds, maybe javadoc should write a warning.   But that 
is all more than I wanted to do at this stage in the release.

-- Jon


On 6/8/18 7:13 AM, Hannes Wallnöfer wrote:
> I noticed that the old getLocale code used underscore as separator while LanguageTag uses hyphen. Isn’t that a problem?
>
> The main method of the VerifyLocale test uses a mix of tab and spaces for indentation.
>
> Otherwise looks good to me.
>
> Hannes
>
>
>> Am 08.06.2018 um 01:45 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
>>
>> Improved webrev, that uses Locale.Builder to detect syntactically bad locales.
>>
>> Webrev: http://cr.openjdk.java.net/~jjg/8149565/webrev.00/index.html
>>
>> -- Jon
>>
>> On 06/07/2018 03:19 PM, Jonathan Gibbons wrote:
>>> Please review a relatively simple fix to a problem that was found a while back relating to the handling of the -locale option.
>>>
>>> The fix is to change some old code, that did not work on all locales installed in a standard JDK build, with the use of Locale.forLanguageTag, added in JDK 7. This method supports IETF BCP 47 language tag strings.
>>>
>>> The test is removed from the problem list and updated to work correctly.  The primary error in the test as originally written was that the doclet invocation would create the doclet instance in a distinct classloader, and thus not share static members, as was clearly the intent.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149565
>>> Webrev: http://cr.openjdk.java.net/~jjg/8149565/webrev.00/index.html
>>>
>>> -- Jon