[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577486#action_12577486 ]
Vemund Østgaard commented on DERBY-3320: ---------------------------------------- My understanding is along the lines of what Knut writes, that the set of locales supported by Collator and Locale in theory can be different. If collation=TERRITORY_BASED the selected locale should be one of those returned by Collator.getAvailableLocales(). See also my comment on Jan. 25. 08. > 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.