[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577171#action_12577171
]
Mamta A. Satoor commented on DERBY-3320:
----------------------------------------
Sorry for the brief comment "making sure that Collator can be instantiated for
the locale on a give JVM ". Let me elaborate on what I am thinking of doing.
Collator class has a method called getAvailableLocales which returns an array
of locales which are the union of locales supported by the Java runtime and by
installed CollatorProvider(a subclass of LocaleServiceProvider)
implementations.
Locale class also has a method called getAvailableLocales which returns an
array of locales which are the union of locales supported by the Java runtime
and by installed LocaleServiceProvider implementations.
So, it appears that the locale arrary returned from
Collator.getAvailableLocales will be a subset of locale array returned by
Locale.getAvailableLocales
What I was thinking of doing was adding a new method (don't know in which class
at this point) which will go through the arrary returned by
Collator.getAvailableLocales and see if the locale requested by the user is
included in the locale arrary. If not, then throw an exception. I was planning
on calling this method when I find at database create/boot time that user has
asked for territory based collation.
After thinking more about it, I think it will be better for us to make the new
method more generic by going through Locale.getAvailableLocales rather than the
Collator.getAvailableLocales. And then seee if the locale requested by the user
is inclueded in the locale array. Making the method generic this way will
enable us to use it for other Derby functionality that uses the database locale
(some of this functionality has been identified by Dan in his earlier comment
to this jira entry).
> 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.
