-
Bug
-
Resolution: Fixed
-
P2
-
None
-
b06
-
Verified
Scanario:
When I invoke -
DateFormatSnymbols.getInstance(Locale.forLanguageTag("en-US-u-rg-AAzzzz"));
Where en-US supported by JDK but en-AA is not, but provided as extension by the installed providers.
Expectation:
The installed provider should be invoked for the en-AA support.
Observation:
The implementation first look for "en-US" locale support, if the
JDK has support for this and does not have support for "en-AA" then it will fallback.
I don't think it will look for installed providers for "en-AA" in this case.
As per spec : LocaleServiceProvider
"When checking whether a locale is supported, the locale's extensions
are ignored by default. (If locale's extensions should also be
checked, the isSupportedLocale method must be overridden.)
I also overridden the isSupportedLocale(), but still the extension is not considered by JDK implementation.
Attached the standalone code, to demonstrate this.
When I invoke -
DateFormatSnymbols.getInstance(Locale.forLanguageTag("en-US-u-rg-AAzzzz"));
Where en-US supported by JDK but en-AA is not, but provided as extension by the installed providers.
Expectation:
The installed provider should be invoked for the en-AA support.
Observation:
The implementation first look for "en-US" locale support, if the
JDK has support for this and does not have support for "en-AA" then it will fallback.
I don't think it will look for installed providers for "en-AA" in this case.
As per spec : LocaleServiceProvider
"When checking whether a locale is supported, the locale's extensions
are ignored by default. (If locale's extensions should also be
checked, the isSupportedLocale method must be overridden.)
I also overridden the isSupportedLocale(), but still the extension is not considered by JDK implementation.
Attached the standalone code, to demonstrate this.