[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585564#action_12585564
]
Vemund Østgaard commented on DERBY-3320:
----------------------------------------
I'm not sure if there is any easy way to accomplish what you want.
What comes to mind is that I think you could write your own CollatorProvider.
This CollatorProvider could be written in a way that allows you to instrument
it to behave the way you want. This CollatorProvider would extend the support
in the jdk/jre with some dummy Collator for a made up Locale when you want it
to. Then, when you want it to no longer provide support for that Locale, you
just tell it not to by setting a property or something. Basically you could
just tell it to support any Locale, the jre will call a method:
public abstract Collator getInstance(Locale locale)
that you implement yourself in your CollatorProvider.
The javadoc for LocaleServiceProvider says a bit about how to package such an
extension. I don't know if this is a feasible path but it might be worth
looking into.
> 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_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.
