[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562434#action_12562434
]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
I am not sure if there is an easier way to check for Locale support, I used
your method when making a patch for the tests to avoid running them when the
locale to test with was not available. It has not been committed yet, though.
I think maybe that Locale.getAvailableLocales() doesn't necessarily have to
return the same list of supported Locales as Collator.getSupportedLocales(), or
other locale-dependent classes with the getSupportedLocales() method. So maybe
it is important to check what returned by the functionality that will be used,
like Collator.
Take a look at the javadoc for java.util.spi.LocaleServiceProvider, it seems
all the different locale-dependant provider classes are subclasses of this. The
second last paragraph says:
Locale sensitive factory methods and methods for name retrieval in the
java.text and java.util packages invoke service provider methods when needed to
support the requested locale. The methods first check whether the Java runtime
environment itself supports the requested locale, and use its support if
available. Otherwise, they call the getAvailableLocales() methods of installed
providers for the appropriate interface to find one that supports the requested
locale. If such a provider is found, its other methods are called to obtain the
requested object or name. If neither the Java runtime environment itself nor an
installed provider supports the requested locale, a fallback locale is
constructed by replacing the first of the variant, country, or language strings
of the locale that's not an empty string with an empty string, and the lookup
process is restarted. In the case that the variant contains one or more '_'s,
the fallback locale is constructed by replacing the variant with a new variant
which eliminates the last '_' and the part following it. Even if a fallback
occurs, methods that return requested objects or name are invoked with the
original locale before the fallback.The Java runtime environment must support
the root locale for all locale sensitive services in order to guarantee that
this process terminates.
So, I think you will have to go through the list of supported locales for the
functionality that will be used. Maybe that is only Collator?
Something to consider is also whether you need an exact match to consider a
locale supported for the purpose of the Collator, or if it is enough to get a
language match? For instance, if looking for en_GB, is en_US good enough? Maybe
if a partial match is found, the DB should be allowed to boot but write a
warning about it only finding a partial match?
> Database creation and boot should fail if collation=TERRITORY_BASED and the
> selected locale is not supported
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3320
> URL: https://issues.apache.org/jira/browse/DERBY-3320
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.4.0.0
> Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
> GNU/Linux
> Reporter: Vemund Østgaard
> Assignee: Mamta A. Satoor
> Attachments: DERBY_3320_Repro.java
>
>
> A problem I've discovered when testing with the phoneME advanced platform is
> that the collationtests expect other locales than Locale.US to be available
> on the platform that is used for the test, and for phoneME advanced (when
> compiled as foundation profile) only Locale.US is available. From the jdk1.6
> javadoc of Collator.getAvailableLocales() I see that only Locale.US is
> strictly required:
> public static Locale[] getAvailableLocales()
> Returns an array of all locales for which the getInstance methods of this
> class can return localized instances. The returned array represents the union
> of locales supported by the Java runtime and by installed CollatorProvider
> implementations. It must contain at least a Locale instance equal to
> Locale.US.
> Returns:
> An array of locales for which localized Collator instances are
> available.
> This led me to thinking about how Derby should behave if created/booted with
> collation=TERRITORY_BASED and territory=<some unsupported locale>. I'm not
> sure what the consequences could be if the database is first created on a
> platform that supports whatever locale is set and later booted with one that
> doesn't, or created on a platform missing support and later booted with one
> that has. In any case I think it may confuse a user needlessly to see the
> database boot successfully with his collation setting and later behave in a
> way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and
> boot should fail if collation=TERRITORY_BASED and the selected locale is not
> supported.
> If a change like this is implemented, the collationtests should be changed to
> verify correct behavior also if they are executed in an environment were some
> of the tested locales are not supported.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
