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 <[email protected]>:
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
