JDK-8001562 : Collator.getAvailableLocales() doesn't return all locales for which localized instances are available
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-10-25
  • Updated: 2012-11-19
  • Resolved: 2012-11-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8 b65Fixed
Related Reports
Relates :  
The javadoc for Collator.getAvailableLocales() says:

"Returns an array of all locales for which the getInstance methods of this class can return localized instances."

In JDK 8, after JDK-7171324, many locales have been removed from the returned array, but localized instances could still be obtained for them.

For example, both Collator.newInstance(Locale.JAPAN) and Collator.newInstance(Locale.JAPANESE) return a collator localized for Japanese, but only Locale.JAPANESE is in the returned array, so getAvailableLocales() doesn't return *all* locales for which localized instances could be obtained.

This may cause compatibility problems for existing applications that use collators. If they check getAvailableLocales() before creating collators, they may work fine in ja_JP locale (and others) on JDK 7 and earlier, and stop working in that locale when they upgrade to JDK 8.

For the applications that check the return value of getAvailableLocales() it's probably better if it returns all the locales it used to return in JDK 7.
There were many failures in the Java DB regression tests because of this issue. I reran the tests with b65, and now they were all successful. Thanks for fixing it!

The confusion all begins with the definition of "available." The spec reads they are the locales where localized object can be returned, but what about "ja_US" locale? It's not in the "available" list but still it returns Japanese collator (as the result of ResourceBundle fallback). Thus we implemented in a way described in 7171324, where available locales reflect the locales that actually have resources. However, looking at this issue and discussed with my colleague, we've decided to keep the compatibility with JDK7 as we don't want to break existing applications. We thought the compatibility risk by implementing 7171324 was minimal, but not sure anymore.