[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586933#action_12586933 ]
Mamta A. Satoor commented on DERBY-3320: ---------------------------------------- I have added jira entry DERBY-3608 for 2 additional test cases that could be added. > 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 > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt, > DERBY_3320_Collator_Support_Check_stat_v2.txt, > DERBY_3320_not_ready_for_commit_diff_v1.txt, > DERBY_3320_not_ready_for_commit_stat_v1.txt, 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.