db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vemund Ostgaard <Vemund.Ostga...@Sun.COM>
Subject Setting collation=TERRITORY_BASED when territory is set to an unsupported locale
Date Mon, 14 Jan 2008 13:12:33 GMT
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>[]

    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

        An array of locales for which localized |Collator| instances are

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?


View raw message