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
<http://java.sun.com/javase/6/docs/api/java/util/Locale.html>[]
*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|
<http://java.sun.com/javase/6/docs/api/java/text/spi/CollatorProvider.html>
implementations. It must contain at least a Locale instance equal to
|Locale.US|
<http://java.sun.com/javase/6/docs/api/java/util/Locale.html#US>.
*Returns:*
An array of locales for which localized |Collator| instances are
available.
My thought on this is to change the collationtests to check if for
instance a Collator for polish locale is available before running the
test for polish collation.
This however 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.
So, should database creation/boot fail if the collation is territory
based and the locale is not supported?
Vemund
